Hi, Patch b134ea74331b is to make repush remmeber the scrolling position. This is, if you load a page, start scrolling and the stylesheet arrives after that, it will no longer go back to the top. Please test. -- Cheers Jorge.-
On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote:
Patch b134ea74331b is to make repush remmeber the scrolling position. This is, if you load a page, start scrolling and the stylesheet arrives after that, it will no longer go back to the top.
Please test.
Works for me with Slashdot. Very nice! Regards, Jeremy Henty
On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote:
On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote:
Patch b134ea74331b is to make repush remmeber the scrolling position. This is, if you load a page, start scrolling and the stylesheet arrives after that, it will no longer go back to the top.
Please test.
Works for me with Slashdot. Very nice!
Yes, works great. One minor thing, which also happens when going back/forward: It seems that the page is first drawn with scroll position 0 and then immediately scrolled down to the remembered scroll position. Any ideas where the first redraw comes from? Maybe we can eliminate that? Regards, Johannes
On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote:
On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote:
On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote:
Patch b134ea74331b is to make repush remmeber the scrolling position. This is, if you load a page, start scrolling and the stylesheet arrives after that, it will no longer go back to the top.
Please test.
Works for me with Slashdot. Very nice!
Yes, works great.
One minor thing, which also happens when going back/forward:
It seems that the page is first drawn with scroll position 0 and then immediately scrolled down to the remembered scroll position. Any ideas where the first redraw comes from? Maybe we can eliminate that?
Yes, I've noticed this and share the feel on it! Maybe there's a redraw request for pos. 0, and then the scroll jump. If the jump is made from a timeout function, then the first draw will always complete. I haven't checked the code though. -- Cheers Jorge.-
On Thu, Feb 12, 2009 at 11:52:27AM -0300, Jorge Arellano Cid wrote:
On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote:
On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote:
On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote:
Patch b134ea74331b is to make repush remmeber the scrolling position. This is, if you load a page, start scrolling and the stylesheet arrives after that, it will no longer go back to the top.
Please test.
Works for me with Slashdot. Very nice!
Yes, works great.
One minor thing, which also happens when going back/forward:
It seems that the page is first drawn with scroll position 0 and then immediately scrolled down to the remembered scroll position. Any ideas where the first redraw comes from? Maybe we can eliminate that?
Yes, I've noticed this and share the feel on it!
Maybe there's a redraw request for pos. 0, and then the scroll jump. If the jump is made from a timeout function, then the first draw will always complete.
I haven't checked the code though.
After a skim, that's exactly the case. Even more there's a FltkViewBase::cancelQueueDraw() function that looks very much like what we need. The only caveat is that it's not implemented yet! :-) -- Cheers Jorge.-
On Thu, Feb 12, 2009 at 12:09:43PM -0300, Jorge Arellano Cid wrote:
On Thu, Feb 12, 2009 at 11:52:27AM -0300, Jorge Arellano Cid wrote:
On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote:
On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote:
On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote:
Patch b134ea74331b is to make repush remmeber the scrolling position. This is, if you load a page, start scrolling and the stylesheet arrives after that, it will no longer go back to the top.
Please test.
Works for me with Slashdot. Very nice!
Yes, works great.
One minor thing, which also happens when going back/forward:
It seems that the page is first drawn with scroll position 0 and then immediately scrolled down to the remembered scroll position. Any ideas where the first redraw comes from? Maybe we can eliminate that?
Yes, I've noticed this and share the feel on it!
Maybe there's a redraw request for pos. 0, and then the scroll jump. If the jump is made from a timeout function, then the first draw will always complete.
I haven't checked the code though.
After a skim, that's exactly the case.
Even more there's a FltkViewBase::cancelQueueDraw() function that looks very much like what we need.
The only caveat is that it's not implemented yet! :-)
I'm working on it... -- Cheers Jorge.-
On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote:
On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote:
On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote:
Patch b134ea74331b is to make repush remmeber the scrolling position. This is, if you load a page, start scrolling and the stylesheet arrives after that, it will no longer go back to the top.
Please test.
Works for me with Slashdot. Very nice!
Yes, works great.
One minor thing, which also happens when going back/forward:
It seems that the page is first drawn with scroll position 0 and then immediately scrolled down to the remembered scroll position. Any ideas where the first redraw comes from? Maybe we can eliminate that?
I thought that with the implementation of cancelQueueDraw(), and the respective call from scrollTo() it would work, but I was wrong. The attached patch implements cancelQueueDraw() and adds some debugging messages that show interesting facts: Nav_open_url: new url='dpi:/bm/' FltkViewBase::cancelQueueDraw() Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw FltkViewBase::cancelQueueDraw() FltkViewBase::cancelQueueDraw() FltkViewBase::draw Nav_open_url: new url='http://localhost/htdocs/redraw.html' FltkViewBase::cancelQueueDraw() Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw FltkViewBase::cancelQueueDraw() FltkViewBase::cancelQueueDraw() FltkViewBase::draw FltkViewBase::draw FltkViewBase::draw FltkViewBase::draw 1.- There's no need for an explicit call to cancelQueueDraw() from Layout::scrollTo0(). It happens anyway. 2.- For bookmarks there's just one draw() call. 3.- For coming back to a scrolled page, there're four calls!!! 4.- I'm using a test page with no repush(): <html><body><img src="image1.png"><br> <ul><li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 </ul></body></html> This could take some time, so I'm handing it back to you now... -- Cheers Jorge.-
On Thu, Feb 12, 2009 at 05:43:08PM -0300, Jorge Arellano Cid wrote:
On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote:
On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote:
On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote:
Patch b134ea74331b is to make repush remmeber the scrolling position. This is, if you load a page, start scrolling and the stylesheet arrives after that, it will no longer go back to the top.
Please test.
Works for me with Slashdot. Very nice!
Yes, works great.
One minor thing, which also happens when going back/forward:
It seems that the page is first drawn with scroll position 0 and then immediately scrolled down to the remembered scroll position. Any ideas where the first redraw comes from? Maybe we can eliminate that?
I thought that with the implementation of cancelQueueDraw(), and the respective call from scrollTo() it would work, but I was wrong.
The attached patch implements cancelQueueDraw() and adds some debugging messages that show interesting facts:
Nav_open_url: new url='dpi:/bm/' FltkViewBase::cancelQueueDraw() Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw FltkViewBase::cancelQueueDraw() FltkViewBase::cancelQueueDraw() FltkViewBase::draw Nav_open_url: new url='http://localhost/htdocs/redraw.html' FltkViewBase::cancelQueueDraw() Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw FltkViewBase::cancelQueueDraw() FltkViewBase::cancelQueueDraw() FltkViewBase::draw FltkViewBase::draw FltkViewBase::draw FltkViewBase::draw
1.- There's no need for an explicit call to cancelQueueDraw() from Layout::scrollTo0(). It happens anyway. 2.- For bookmarks there's just one draw() call. 3.- For coming back to a scrolled page, there're four calls!!! 4.- I'm using a test page with no repush():
<html><body><img src="image1.png"><br> <ul><li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 </ul></body></html>
This could take some time, so I'm handing it back to you now...
It seems that the problem comes from the fact that we scroll to a position that is not valid at the time we do the scrolling (when the page is still empty). In that case Layout::adjustScrollPos() changes the remembered scroll position to 0,0. Only later we scroll to the desired position. This also has to do with how idle functions are handled. Attached patch seems to fix this problem, but I'm not yet proposing it for inclusion, as I don't understand the details. If anyone want's to take a look - please go ahead! Cheers, Johannes
participants (3)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org