patch: more widget coloring
My main forms testing page has bg #00ffff from when I was first experimenting with widget colors. Some time ago, fltk changed so that selected checkboxes and radio buttons use selection_color(). I had this set to the inverse of the background. Red. Not a good combination to say the least. Well, I finally got around to trying to fix it up a little. By the way, I was looking at that big page of inputs with differently-colored backgrounds that I made in February... At the time, I wrote that you guys had gotten the page down to 0:06 to load with clear_double_buffer(), immediate to load without it, and 0:09 to destroy the page. The good news is that it now takes the same amount of time with or without clear_double_buffer(), but the bad news is that it takes 0:12 to load and 0:48 to close.
By the way, I was looking at that big page of inputs with differently-colored backgrounds that I made in February... At the time, I wrote that you guys had gotten the page down to 0:06 to load with clear_double_buffer(), immediate to load without it, and 0:09 to destroy the page.
The good news is that it now takes the same amount of time with or without clear_double_buffer(), but the bad news is that it takes 0:12 to load and 0:48 to close.
If I assume that you can only have one instance of a widget in a view and add a break to the loop in FltkWidgetView::removeFltkWidget() once it finds it, the 0:48 becomes 0:03.
On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote:
By the way, I was looking at that big page of inputs with differently-colored backgrounds that I made in February... At the time, I wrote that you guys had gotten the page down to 0:06 to load with clear_double_buffer(), immediate to load without it, and 0:09 to destroy the page.
The good news is that it now takes the same amount of time with or without clear_double_buffer(), but the bad news is that it takes 0:12 to load and 0:48 to close.
If I assume that you can only have one instance of a widget in a view and add a break to the loop in FltkWidgetView::removeFltkWidget() once it finds it, the 0:48 becomes 0:03.
Ah, interesting. In that case I'd ditch the canvasWidgets list entirely as in attached patch. Cheers, Johannes PS: Can you share that test page?
ok, here's the patch ... On Wed, Sep 10, 2008 at 05:05:34PM +0200, Johannes Hofmann wrote:
On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote:
By the way, I was looking at that big page of inputs with differently-colored backgrounds that I made in February... At the time, I wrote that you guys had gotten the page down to 0:06 to load with clear_double_buffer(), immediate to load without it, and 0:09 to destroy the page.
The good news is that it now takes the same amount of time with or without clear_double_buffer(), but the bad news is that it takes 0:12 to load and 0:48 to close.
If I assume that you can only have one instance of a widget in a view and add a break to the loop in FltkWidgetView::removeFltkWidget() once it finds it, the 0:48 becomes 0:03.
Ah, interesting. In that case I'd ditch the canvasWidgets list entirely as in attached patch.
Cheers, Johannes
PS: Can you share that test page?
Johannes wrote:
On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote:
By the way, I was looking at that big page of inputs with differently-colored backgrounds that I made in February... At the time, I wrote that you guys had gotten the page down to 0:06 to load with clear_double_buffer(), immediate to load without it, and 0:09 to destroy the page.
The good news is that it now takes the same amount of time with or without clear_double_buffer(), but the bad news is that it takes 0:12 to load and 0:48 to close.
If I assume that you can only have one instance of a widget in a view and add a break to the loop in FltkWidgetView::removeFltkWidget() once it finds it, the 0:48 becomes 0:03.
Ah, interesting. In that case I'd ditch the canvasWidgets list entirely as in attached patch.
Cheers, Johannes
PS: Can you share that test page?
I just meant the one generated from the code on: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-February/003760.html
On Wed, Sep 10, 2008 at 05:05:34PM +0200, Johannes Hofmann wrote:
On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote:
By the way, I was looking at that big page of inputs with differently-colored backgrounds that I made in February... At the time, I wrote that you guys had gotten the page down to 0:06 to load with clear_double_buffer(), immediate to load without it, and 0:09 to destroy the page.
The good news is that it now takes the same amount of time with or without clear_double_buffer(), but the bad news is that it takes 0:12 to load and 0:48 to close.
If I assume that you can only have one instance of a widget in a view and add a break to the loop in FltkWidgetView::removeFltkWidget() once it finds it, the 0:48 becomes 0:03.
Ah, interesting. In that case I'd ditch the canvasWidgets list entirely as in attached patch.
I don't know well that part of the code, but IIRC Sebastian used to render the same page into different widgets at the same time (e.g. also to thumbnail-sized one). AFAIU, this patch removes that functionality, which dillo doesn't use by now. Please correct me if I'm wrong. BTW, why was the children drawing order reversed? -- Cheers Jorge.-
Hi Jorge, On Wed, Sep 10, 2008 at 04:50:35PM -0400, Jorge Arellano Cid wrote:
On Wed, Sep 10, 2008 at 05:05:34PM +0200, Johannes Hofmann wrote:
On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote:
By the way, I was looking at that big page of inputs with differently-colored backgrounds that I made in February... At the time, I wrote that you guys had gotten the page down to 0:06 to load with clear_double_buffer(), immediate to load without it, and 0:09 to destroy the page.
The good news is that it now takes the same amount of time with or without clear_double_buffer(), but the bad news is that it takes 0:12 to load and 0:48 to close.
If I assume that you can only have one instance of a widget in a view and add a break to the loop in FltkWidgetView::removeFltkWidget() once it finds it, the 0:48 becomes 0:03.
Ah, interesting. In that case I'd ditch the canvasWidgets list entirely as in attached patch.
I don't know well that part of the code, but IIRC Sebastian used to render the same page into different widgets at the same time (e.g. also to thumbnail-sized one).
AFAIU, this patch removes that functionality, which dillo doesn't use by now. Please correct me if I'm wrong.
I don't think this patch removes any functionality. Not even an unused one. It simply relies on fltk to remember all the child widgets instead of storing them again in a separate list. It's rather the recent FltkViewBase::drawRectangle() changes that affect a scaled down display of the page contents. The initial fix has now been reverted again (Commit messages "reverted a patch in FltkViewBase::drawRectangle").
BTW, why was the children drawing order reversed?
That's because fltk does it that way. Group::find() searches children backwards, so it's faster to e.g remove widgets in reverse order (see comment in Group::find() in the fltk sources). Also Group::children() get's only called once that way. I think it's safe to apply this patch - after some testing on other platforms. Cheers, Johannes.
On Wed, Sep 10, 2008 at 11:07:02PM +0200, Johannes Hofmann wrote:
Hi Jorge,
On Wed, Sep 10, 2008 at 04:50:35PM -0400, Jorge Arellano Cid wrote:
On Wed, Sep 10, 2008 at 05:05:34PM +0200, Johannes Hofmann wrote:
On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote:
By the way, I was looking at that big page of inputs with differently-colored backgrounds that I made in February... At the time, I wrote that you guys had gotten the page down to 0:06 to load with clear_double_buffer(), immediate to load without it, and 0:09 to destroy the page.
The good news is that it now takes the same amount of time with or without clear_double_buffer(), but the bad news is that it takes 0:12 to load and 0:48 to close.
If I assume that you can only have one instance of a widget in a view and add a break to the loop in FltkWidgetView::removeFltkWidget() once it finds it, the 0:48 becomes 0:03.
Ah, interesting. In that case I'd ditch the canvasWidgets list entirely as in attached patch.
I don't know well that part of the code, but IIRC Sebastian used to render the same page into different widgets at the same time (e.g. also to thumbnail-sized one).
AFAIU, this patch removes that functionality, which dillo doesn't use by now. Please correct me if I'm wrong.
I don't think this patch removes any functionality. Not even an unused one. It simply relies on fltk to remember all the child widgets instead of storing them again in a separate list.
It's rather the recent FltkViewBase::drawRectangle() changes that affect a scaled down display of the page contents. The initial fix has now been reverted again (Commit messages "reverted a patch in FltkViewBase::drawRectangle").
BTW, why was the children drawing order reversed?
That's because fltk does it that way. Group::find() searches children backwards, so it's faster to e.g remove widgets in reverse order (see comment in Group::find() in the fltk sources). Also Group::children() get's only called once that way.
I think it's safe to apply this patch - after some testing on other platforms.
Thanks for the explanation. Committed. -- Cheers Jorge.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de