GNOME Bugzilla – Bug 590800
The window content is not updated correctly when scrolling
Last modified: 2010-08-25 02:36:14 UTC
Please describe the problem: When scrolling downward, the content is not updated correctly. Steps to reproduce: 1. Run a test case listed in Gtk-demo 2. Select to view the source codes. 3. Just scroll downward and the problem comes out. Actual results: Expected results: Does this happen every time? Yes Other information: At gdk/directfb/gdkgeometry-directfb.c:249 In function _gdk_directfb_window_move_region() impl->surface->Blit (impl->surface, impl->surface,&source,dx,dy) should not use (dx, dy) as a destination anymore. When dx or dy is negative, the destination calculated is not right.
Created attachment 139921 [details] [review] Fix for position bug Fix for position bug
Michael, are you going to commit that fix ?
(In reply to comment #2) > Michael, are you going to commit that fix ? > Can you or someone else ? I've been sitting on it for almost a month trying to find time to set up a nice head build of GTK for committing now I have to travel for several weeks :( I've got a couple of other patches to gdk itself ( bugs in the builtin blit code) I promise I'll at least get everything I'm setting on out as bug reports asap. More than that will be tough. Also I created a nice virtual surface for cairo I'll push that to the cairo list today.
Sure, I'll take care of it.
(In reply to comment #4) > Sure, I'll take care of it. > Thanks the virtual surface patch is now on the cairo list. Hope people find it useful. Now a few more patches and bug reports and I can sleep at night :)
Michael, The patch is not working for me. There is the problem: When moving a area start at (0, 0) to destination (0, -40). The dest_extents is calculated by adding the clipping area which is (0, 0, width, height). Therefore, the dest_extents is (0, 0, width, height-40). Source area is calculated by dest_extents.y - dy (dy = -40). That is to say, according to dest_extents calculation. When dx = 0 and dy=-40. Source area will be (0, 40, width, height+dy) Dest area will be (0, 0, width, height+dy). It's definitely right. But the Blit function still use a destination (dx, dy), I think that's the problem. When dx < 0 or dy < 0, we should not blit to (dx, dy) anymore. Blit to (dest_extents.x, dest_extents.y) is okay.
(In reply to comment #6) > Michael, The patch is not working for me. > There is the problem: > When moving a area start at (0, 0) to destination (0, -40). > The dest_extents is calculated by adding the clipping area which is (0, 0, > width, height). > Therefore, the dest_extents is (0, 0, width, height-40). > Source area is calculated by dest_extents.y - dy (dy = -40). > > That is to say, according to dest_extents calculation. > When dx = 0 and dy=-40. > Source area will be (0, 40, width, height+dy) Dest area will be (0, 0, width, > height+dy). > It's definitely right. But the Blit function still use a destination (dx, dy), > I think that's the problem. > When dx < 0 or dy < 0, we should not blit to (dx, dy) anymore. > Blit to (dest_extents.x, dest_extents.y) is okay. > Well the patch is correct IMHO however there is a second bug that needs and additional patch so you need this then I think more to fix what your saying. I think you need both if you can patch the blit routine however make sure you do it right looks like the clip is wrong to me not the blit i.e its not clipping correctly for -dx -dy. Can you create and additional patch for the blit ?
Comment on attachment 139921 [details] [review] Fix for position bug commit 04d7d8105629532875d2bf1c3a454184fd6d1b40
The directfb backend has been removed form GTK 3