Re: [jbosstools-dev] VPE editor
Max,
I haven't applied the patch because I have some changes in my code.
However, I have seen that you are using the following method:
proxyNode =
(nsIDOMNode)getProxyObjectManager().getProxyForObject(getEventQueue(),
nsIDOMNode.NS_IDOMNODE_IID,
node,
nsIProxyObjectManager.INVOKE_SYNC);
The method:
private static nsIEventQueue getEventQueue() {
if(eventQueue==null) {
nsIServiceManager serviceManager =
Mozilla.getInstance().getServiceManager();
nsIEventQueueService eventQueueServive =
(nsIEventQueueService)serviceManager.getServiceByContractID("(a)mozilla.org/event-queue-service;1",nsIEventQueueService.NS_IEVENTQUEUESERVICE_IID);
//$NON-NLS-1$
eventQueue =
eventQueueServive.getSpecialEventQueue(nsIEventQueueService.UI_THREAD_EVENT_QUEUE);
}
return eventQueue;
}
returns event queue in the UI thread what means that your proxy is
created in the UI thread. That is required behavior for
mozilla/xulrunner methods.
The getProxyObjectManager() method is called with the INVOKE_SYNC flag.
This means that you could get a such behavior if you called
notifyChangedInUiThread with display.asyncExec like the following:
VpeController.java (notifyChanged(...) around line 379)
- if (display != null && (Thread.currentThread() == display.getThread())) {
- notifyChangedInUiThread(notifier, eventType, feature, oldValue,
newValue, pos);
- return;
- }
+if (display != null && (Thread.currentThread() == display.getThread())) {
+ display.asyncExec(new Runnable() {
+ public void run() {
+ notifyChangedInUiThread(notifier, eventType,
feature, oldValue, newValue, pos);
+ }
+ });
+ return;
+ }
I believe that you have got the following behavior:
- when a user enter a key, it is shown immediately, but the user waits
for the notifyChanged method to finish, like before.
Snjeza
Max Areshkau wrote:
Snjezana Peco wrote:
> Max Areshkau wrote:
>> Snjezana Peco wrote:
>>> Max Rydahl Andersen wrote:
>>>>>> Doing it in a seperate thread is a different enhancement I
>>>>>> think, but definitly
>>>>>> also worth it. The current idea is just to not update on every
>>>>>> stroke since users
>>>>>> would normally write more than one letter and while he is typing
>>>>>> the visual view
>>>>>> does not need to be updated 100% live (especially not when its
>>>>>> update seem to be
>>>>>> so slow in special cases).
>>>>>>
>>>>>>
>>>>>>
>>>>> I have tried to separate of visual editor update on user input into
>>>>> different thread(you can see commnets for JBIDE-675),
>>>>> and I founded following problems:
>>>>> 1) Modifications of nsIDOM* nodes can be done only in UI thread,
>>>>> if it's
>>>>> done in non UI thread it's crashes a
>>>>> eclipse.
>>>>> 2)If we update nodes in UI thread, the user input thread are
>>>>> suspended.
>>>>>
>>>>
>>>> Too bad ;( Do we know why there is this limitation ?
>>>>
>>>>
>>>
>>> Mozilla requires DOM modifications to be done in the UI thread. It
>>> is possible to split the VPE action (notifyChanged) into the UI and
>>> non-UI part.
>>> This wouldn't be trivial.
>>>
>>> Snjeza
>> Looks like we can modify DOM not only from UI thread, for it we
>> should use proxy objects (nsIProxyObjectManager), according following
>> documentation
>>
http://developer.mozilla.org/en/docs/JavaXPCOM:Embedding_Mozilla_in_a_Jav....
>>
>>
>
> The article is talking about calling XPCOM UI from another thread (in
> Eclipse, you can do it using display.syncExec() or
> display.asyncExec()). However, you can't execute XPCOM methods in
> non-UI thread. In most of the cases, that would crash the
> application. You can separate non-UI part from the UI part and call
> XPCOM UI using the mentioned methods.
>
> Snjeza
>
I have tried to implement creation of proxy for modification DOM
nodes and with it's eclipse doesn't crashes and user can edit source
page while visual
part is updated. I have attached my changes. If I run the some code
without proxy eclipse crashes, but with proxy objects it's works.
XPCOM methods are executed from non ui thread.