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