dialog overlay slowness

[Wichert Akkerman]

All the extra work the overlay for modal dialogs does is hurting me
badly: testers are reporting that the site is incredibly slow, and
especially with webkit nightlies it is impossible to use a form inside
a panel.

Personally I consider preventing the user from navigating to something
underneath the overlay an edge-case that I might not care about,
especially if that means choosing between decent and dreadful
performance.

What are the current plans for dealing with this issue?

Wichert.

--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

[Wichert Akkerman]

Previously Wichert Akkerman wrote:
> All the extra work the overlay for modal dialogs does is hurting me
> badly: testers are reporting that the site is incredibly slow, and
> especially with webkit nightlies it is impossible to use a form inside
> a panel.
>
> Personally I consider preventing the user from navigating to something
> underneath the overlay an edge-case that I might not care about,
> especially if that means choosing between decent and dreadful
> performance.

I timed this on a project I'm working on using IE6: the dialog overlay
slows the dialog opening down from 5 seconds to 25 seconds. That is a
full 20 seconds slowdown!

[Wichert Akkerman]

Previously Wichert Akkerman wrote:
>
> Previously Wichert Akkerman wrote:
> > All the extra work the overlay for modal dialogs does is hurting me
> > badly: testers are reporting that the site is incredibly slow, and
> > especially with webkit nightlies it is impossible to use a form inside
> > a panel.
> >
> > Personally I consider preventing the user from navigating to something
> > underneath the overlay an edge-case that I might not care about,
> > especially if that means choosing between decent and dreadful
> > performance.
>
> I timed this on a project I'm working on using IE6: the dialog overlay
> slows the dialog opening down from 5 seconds to 25 seconds. That is a
> full 20 seconds slowdown!

While stripping a local copy of the dialog down I noticed something
unexpected: 10 seconds of that delay is due to the resize handler.

[Scott González]

On Wed, Feb 18, 2009 at 5:30 AM, Wichert Akkerman <wic...@wiggy.net> wrote:

While stripping a local copy of the dialog down I noticed something
unexpected: 10 seconds of that delay is due to the resize handler.

Have you tried using an overlay that doesn't have transparency?  That might help a lot in IE.

[Scott González]

Also, if you're using bgiframe, that will slow things down quite a bit as well.

[Scott González]

The current plan is to look at this for 1.8.  I think we might be able to get big improvements by binding an event handler to the .ui-dialog elements to flag the event as being allowed.  Then bind an event handler to the body that cancels the event if it wasn't flagged as being allowed.  This isn't ideal because it lets the event bubble pretty far up allowing other event handlers to run, but as you've said this may be an edge case.

[Wichert Akkerman]

Can we at least get an option to disable the overlay in 1.7?

Wichert.

[Scott González]

On Wed, Feb 18, 2009 at 7:17 AM, Wichert Akkerman <wic...@wiggy.net> wrote:

Can we at least get an option to disable the overlay in 1.7?

Disable the overlay or disable the overlay event handlers?

[Wichert Akkerman]

Both possibly. There can be good reasons to not use the stock overlay,
for example the ability to use animations to reveal the overlay.

I did a few rough timings to see what influences the performance. All
timings are for opening the same modal dialog, using IE6 on XP SP2.

- original code (as in rc6): 27.8 seconds
- without keypress.ui-dialog binding in dialog.open: 24.2 seconds
- without keyboard handling in overlay: 25.3 seconds
- without resize handler binding in overlay: 8.0 seconds
- all keyboard binding and resize options disabled: 7.3 seconds
- skip overlay creation in dialog.open: 6.3 seconds

Changing the opacity of the overlay did not seem to change the timings.
No bgi was used.

The resize handler is triggered very, very, very often even if you do
not resize the browser.

[Scott González]

On Wed, Feb 18, 2009 at 7:42 AM, Wichert Akkerman <wic...@wiggy.net> wrote:

The resize handler is triggered very, very, very often even if you do
not resize the browser.

Thanks for those numbers, that's really helpful.  Are you talking about the event handler bound to window resize or the actual resize method $.ui.dialog.overlay.resize?  If it's the event handler, can you see what happens if you add a check for event.target to be the window and bail out if it's not.  I'm not sure which target we actually need to check for: body, document, window, I'm assuming window.  If this is in fact the biggest contributor, we can definitely fix that for this release.

[Wichert Akkerman]

event.target is indeed never the window, so I'm guessing those are
bubbled events generated when doing layout or DOM manipulations.

Testing for event.target and bailing out if event.target!==window halves
the time spend on resizing logic, which still leaves a sizable delay.

[Todd Parker]

Even 6 seconds to open a dialog seems really odd. If we can reproduce
these long delays in our tests for IE 6, I'd say there is something
very wrong with the dialog code and we should consider this to be a
potential blocker for 1.7. A dialog should really take much less than
a second to open or it will appear to be 'broken' to an end user.
After 1 second of latency, you'd need to provide a spinner to at least
let people know something is happening. I don't think anyone would
wait 20+ seconds for a dialog to open without some feedback.

Wichert - can you provide some info on the complexity of the base page
and the dialog contents? I'm also curious about the specs of your test
machine.

_t

On Feb 18, 9:16 am, Wichert Akkerman <wich...@wiggy.net> wrote:
> Previously Scott González wrote:

> > On Wed, Feb 18, 2009 at 7:42 AM, Wichert Akkerman <wich...@wiggy.net> wrote:
>
> > > The resize handler is triggered very, very, very often even if you do
> > > not resize the browser.
>
> > Thanks for those numbers, that's really helpful.  Are you talking about the
> > event handler bound to window resize or the actual resize method
> > $.ui.dialog.overlay.resize?  If it's the event handler, can you see what
> > happens if you add a check for event.target to be the window and bail out if
> > it's not.  I'm not sure which target we actually need to check for: body,
> > document, window, I'm assuming window.  If this is in fact the biggest
> > contributor, we can definitely fix that for this release.
>
> event.target is indeed never the window, so I'm guessing those are
> bubbled events generated when doing layout or DOM manipulations.
>
> Testing for event.target and bailing out if event.target!==window halves
> the time spend on resizing logic, which still leaves a sizable delay.
>
> Wichert.
>
> --

> Wichert Akkerman <wich...@wiggy.net>    It is simple to make things.http://www.wiggy.net/                  It is hard to make things simple.

[Richard D. Worth]

Here's the ticket:

http://dev.jqueryui.com/ticket/2807

I agree this should be a blocker.

- Richard

[Wichert Akkerman]

Previously Todd Parker wrote:
> Even 6 seconds to open a dialog seems really odd. If we can reproduce
> these long delays in our tests for IE 6, I'd say there is something
> very wrong with the dialog code and we should consider this to be a
> potential blocker for 1.7. A dialog should really take much less than
> a second to open or it will appear to be 'broken' to an end user.
> After 1 second of latency, you'd need to provide a spinner to at least
> let people know something is happening. I don't think anyone would
> wait 20+ seconds for a dialog to open without some feedback.
>
> Wichert - can you provide some info on the complexity of the base page
> and the dialog contents? I'm also curious about the specs of your test
> machine.

I'm not sure how to give a good indication of complexity. The panel
implemented by AJAX-loading a subset of another page and opening that in
a panel. Rendering that whole page takes about 1 second in IE6. The
same javascript code for event binding and DOM manipulation is run in
both cases (slightly less if you use a panel since there are less
elements to process).

I'm testing this on a XP virtual machine running in VMWare fusion on an
iMac, and browsing performance in that VM is normal for other sites.

I can give a login for a test environment that shows this problem if
someone wants to see this.

Wichert.

--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.

[Scott González]

Hey Wichert,

r2103-2105 should fix all of these issues.  I tracked down the following three problems:

1) Opening a dialog was slow because of the calculations to move the dialog to the top. 
2) Using form elements inside a modal dialog was slow because of the event handling.
3) Closing a modal dialog was slow because of the event unbinding.

Dialogs (both modal and non-modal) are now much more performant in IE.  Can you try out latest SVN and let me know if this fixes all of your problems?

[Wichert Akkerman]

Previously Scott González wrote:
> Hey Wichert,
>
> r2103-2105 should fix all of these issues. I tracked down the following
> three problems:
>
> 1) Opening a dialog was slow because of the calculations to move the dialog
> to the top.
> 2) Using form elements inside a modal dialog was slow because of the event
> handling.
> 3) Closing a modal dialog was slow because of the event unbinding.
>
> Dialogs (both modal and non-modal) are now much more performant in IE. Can
> you try out latest SVN and let me know if this fixes all of your problems?

I'm afraid IE6 immediately bombs with an "object expexted" error while
loading the javascript.

[Scott González]

On Thu, Feb 19, 2009 at 8:47 AM, Wichert Akkerman <wic...@wiggy.net> wrote:

I'm afraid IE6 immediately bombs with an "object expexted" error while
loading the javascript.

I'm not seeing any errors locally or on any of the demos from trunk in IE6.

[Wichert Akkerman]

Hm, that's odd. I'll try to debug that later today or tomorrow.

[Glen]

I am also experiencing this issue with IE6 & 7. I do not have access
to a SVN client right now, is there a way I can get the latest code
without one?

Glen

On Feb 19, 8:56 am, Wichert Akkerman <wich...@wiggy.net> wrote:
> Previously Scott González wrote:

> > On Thu, Feb 19, 2009 at 8:47 AM, Wichert Akkerman <wich...@wiggy.net> wrote:
>
> > > I'm afraid IE6 immediately bombs with an "object expexted" error while
> > > loading the javascript.
>
> > I'm not seeing any errors locally or on any of the demos from trunk in IE6.
>
> Hm, that's odd. I'll try to debug that later today or tomorrow.
>
> Wichert.
>
> --

> Wichert Akkerman <wich...@wiggy.net>    It is simple to make things.http://www.wiggy.net/                  It is hard to make things simple.

[Richard D. Worth]

On Thu, Feb 26, 2009 at 6:42 PM, Glen <kirr...@gmail.com> wrote:

I am also experiencing this issue with IE6 & 7. I do not have access
to a SVN client right now, is there a way I can get the latest code
without one?

http://jquery-ui.googlecode.com/svn/trunk/

- Richard
 

[mctpursuer]

Hi,

I tried the most recent jQuery core & UI, I am still having problem
with the dialog when the backgound HTML page is large and using IE6,
it takes very long time to open & close the dialog and to interact
with the dropdown list box and text box within the dialog. However it
works fine under Firefox.

Does anyone know how to solve this issue. I found this issue very late
util I have used the dialog in many place in my project.

Thanks.

On Feb 27, 1:44 pm, "Richard D. Worth" <rdwo...@gmail.com> wrote:

[Richard D. Worth]

Some work has been done on this, so it should be better in the latest version:

http://jquery-ui.googlecode.com/svn/trunk/ui/ui.dialog.js

- Richard

[Scott González]

Here's our test file: http://jquery-ui.googlecode.com/svn/trunk/tests/visual/dialog/dialog_on_page_with_large_dom.html

Works pretty fast for me in IE6.

[Jörn Zaefferer]

Apart from the different layout/size and the missing bgiframe-fix, it's fast!

Jörn

> - Show quoted text -
>
> >
>