Re: [qooxdoo-devel] Chrome redraw problem, fixed by referencing element.offsetHeight in qx.html.Element

2012-05-03 Thread Martin Wittemann
Hey,
> I would be interested about performance comparison of the whole layer.
Me too. ;)

> Browsers today are really optimized and I think that the layer is not
> needed anymore (it only consumes memory to store the shadowed
> properties and slow-downs the function calls related to dom
> manipulation).
The layer is not only about performance. It also brings in an abstraction and 
convenience. 

> If I remember correctly the whole layer was written
> mainly to speed-up IE6, which is now a dead browser.
> 
> Maybe it's ironic, but I really think that removing such layer could
> make qooxdoo apps run faster :)

Yes, that could be true but could also be false. Honestly, I don't know. But 
even if, I don't expect it that much faster compared to the work we would need 
to put in to get the layer out. And again, we could not remove the whole layer, 
only the queueing because most of the other code is convenience for the UI 
layer on top.

Regards,
Martin
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


Re: [qooxdoo-devel] Chrome redraw problem, fixed by referencing element.offsetHeight in qx.html.Element

2012-05-03 Thread Petr Kobalíček
Hi Martin,

I would be interested about performance comparison of the whole layer.
Browsers today are really optimized and I think that the layer is not
needed anymore (it only consumes memory to store the shadowed
properties and slow-downs the function calls related to dom
manipulation). If I remember correctly the whole layer was written
mainly to speed-up IE6, which is now a dead browser.

Maybe it's ironic, but I really think that removing such layer could
make qooxdoo apps run faster :)

Best regards
Petr

On Thu, May 3, 2012 at 5:25 PM, Martin Wittemann
 wrote:
> Hey,
>
> Doing a stripped down example is something I definitely want to do, but at
> the moment the bug is triggered by a complex custom widget (that I can't
> release publicly anyway) so and too I'm backed up against deadlines to try
> and do it just now.
>
> Please file a bug if you have a suitable sample we can reproduce and see
> whats wrong.
>
>
> I might have to release my app with the offsetHeight reference in it - in
> which case, I'd like to run some comparative tests first.  When qx.html was
> developed, were there a series of performance tests developed with it and
> are they still around?
>
> No, unfortunately, thats such a long time ago, we did not add performance
> tests back there.
>
> Regards,
> Martin
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


Re: [qooxdoo-devel] Chrome redraw problem, fixed by referencing element.offsetHeight in qx.html.Element

2012-05-03 Thread Martin Wittemann
Hey,
Doing a stripped down example is something I definitely want to do, but at the 
moment the bug is triggered by a complex custom widget (that I can't release 
publicly anyway) so and too I'm backed up against deadlines to try and do it 
just now.
Please file a bug if you have a suitable sample we can reproduce and see whats 
wrong.


I might have to release my app with the offsetHeight reference in it - in which 
case, I'd like to run some comparative tests first.  When qx.html was 
developed, were there a series of performance tests developed with it and are 
they still around?
No, unfortunately, thats such a long time ago, we did not add performance tests 
back there.

Regards,
Martin

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


Re: [qooxdoo-devel] Chrome redraw problem, fixed by referencing element.offsetHeight in qx.html.Element

2012-05-03 Thread John Spackman
Hi Martin

Doing a stripped down example is something I definitely want to do, but at
the moment the bug is triggered by a complex custom widget (that I can't
release publicly anyway) so and too I'm backed up against deadlines to try
and do it just now.

I might have to release my app with the offsetHeight reference in it - in
which case, I'd like to run some comparative tests first.  When qx.html was
developed, were there a series of performance tests developed with it and
are they still around?

Thanks
John

From:  Martin Wittemann 
Reply-To:  qooxdoo Development 
Date:  Wed, 2 May 2012 09:28:28 +0200
To:  qooxdoo Development 
Subject:  Re: [qooxdoo-devel] Chrome redraw problem, fixed by referencing
element.offsetHeight in qx.html.Element

Hello John,
> It is possible to make the element be visible simply by adding a line to
> qx.html.Element.flush() to reference element.offsetHeight immediately after
> setting the element.style.display.  This is reliably reproducible in my test
> case ­ although the app is not small and concise enough for a playground demo
> right now.
> 
> As a fix this works well, but I'm wondering whether always referencing
> offsetHeight would cause a performance degradation, and are there any tools in
> the Qooxdoo kit to test it?

Querying offestHeight triggers a redraw of the browser and with that, can
sure decrease performance. One reason we introduced the qx.html layer is to
prevent the redraw of the browser so triggering a flush is somehow against
the basic idea of the queue. But the issue seems to be interesting and
should be fixed in the framework it the source of the bug is in the
framework itself. Do you plan to strip your app down to a playground sample?

Regards,
Martin

-- Live Security Virtual Conference Exclusive live event will cover all the
ways today's security and threat landscape has changed and how IT managers
can respond. Discussions will include endpoint security, mobile security and
the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
 qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


Re: [qooxdoo-devel] Chrome redraw problem, fixed by referencing element.offsetHeight in qx.html.Element

2012-05-02 Thread Martin Wittemann
Hello John,
It is possible to make the element be visible simply by adding a line to 
qx.html.Element.flush() to reference element.offsetHeight immediately after 
setting the element.style.display.  This is reliably reproducible in my test 
case – although the app is not small and concise enough for a playground demo 
right now.

As a fix this works well, but I'm wondering whether always referencing 
offsetHeight would cause a performance degradation, and are there any tools in 
the Qooxdoo kit to test it?

Querying offestHeight triggers a redraw of the browser and with that, can sure 
decrease performance. One reason we introduced the qx.html layer is to prevent 
the redraw of the browser so triggering a flush is somehow against the basic 
idea of the queue. But the issue seems to be interesting and should be fixed in 
the framework it the source of the bug is in the framework itself. Do you plan 
to strip your app down to a playground sample?

Regards,
Martin
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel