> 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 ?
Also i have tried to add some delay after change in source editor
before
update visual editor, I have experimented with different delay
intervals, but this doesn't changed the performance situation and
doesn't helped to make vpe more responsible for user.
Well, if you still process all events then sure it will be the same.
The idea is like you describe below to not do an visual page update
until after the user stops typing.
Other way that can usefull for us to improve performance it's
change
event processing in VpeController.notifyChanged, for example
if we add 's' letter to '<te' and get '<tes' first event
what we catch
it's delete event and we removing all child nodes for '<te' tag, than we
catch add and doesn't processing it, and third event is update event which
we catch for parent node of '<tes' and we updating all children nodes
and '<tes' too. Instead of all this for example we can collect all this
events
and in result made only update of '<te' to '<tes', and
doesn't
update parent node and all children nodes.This three modification event
we catch in very short
interval.
-max