Not really. Double-check all your coordinates, though. (For a while, I was logging every coordinate as it passed through every function.)
Avi On Thu, May 14, 2009 at 12:23 PM, Marc-Andre Decoste <[email protected]> wrote: > Here's what we're now doing on the renderer side: > > - In the render widget, we now keep all invalidation as an independent > sub-rect in a vector as opposed to union them as we used to. > - Once, we are ready to paint: > - We create a bitmap that is the size of the whole view and wrap it > in a canvas. > - For each invalidation sub-rec > - We set a clip rect (on the canvas) to the invalidation > sub-rect. > - And then we call WebWidget::Paint() with the canvas and the > sub-rect. > > Anything smells fishy in there? > > BYE > MAD > > > On Thu, May 14, 2009 at 3:14 PM, Avi Drissman <[email protected]> wrote: > >> We haven't drawn one big rectangle for a long while. It took me a while to >> fiddle with the transforms to get it all right, but we correctly blit small >> rectangles for small updates (e.g. cursor blinks). >> >> OTOH, Mike has a point, that getting the coordinate transforms correct is >> important, tricky, and a pain in the rear. That still might be the issue. >> But if you're just calling into the RWHV repeatedly, it should handle it >> just fine. >> >> Avi >> >> On Thu, May 14, 2009 at 12:02 PM, Mike Pinkerton >> <[email protected]>wrote: >> >>> >>> Just off the top of my head, it could be a coordinate problem. Cocoa >>> uses a bottom-left coordinate system (the bottom left of the view is >>> 0,0 as opposed to the top left). Since before we were just drawing a >>> single big rectangle, it might not have mattered if we forgot to do >>> the coordinate flipping. Again, just a wild guess based on things I've >>> seen in the past and differences in the drawing paths. >>> >>> On Thu, May 14, 2009 at 2:33 PM, Marc-Andre Decoste <[email protected]> >>> wrote: >>> > Salut Adam, >>> > The problem is that I'm missing some refreshes... I see them more >>> clearly >>> > when interacting with Google maps, or a little HTML page I created that >>> has >>> > buttons that change the content of scattered table cells to force >>> multiple >>> > individual rect invalidations in one shot... And those don't display if >>> I >>> > try to paint individual rects in the bitmap... >>> > But it all works fine if I paint the whole bitmap, and then only >>> draw the >>> > sub-rects from the bitmap... This is why I think the new Mac specific >>> code >>> > is correct... Otherwise, I don't see how I would see the correct >>> refreshes >>> > in that latter case... Unless I missed something... >>> > >>> > Thanks! >>> > BYE >>> > MAD >>> > On Thu, May 14, 2009 at 2:27 PM, Adam Langley <[email protected]> >>> wrote: >>> >> >>> >> On Thu, May 14, 2009 at 11:21 AM, Marc-Andre Decoste <[email protected]> >>> >> wrote: >>> >> > Since there is a change in the Windows specific code of the >>> renderer >>> >> > host >>> >> > backing store (to draw the sub-rects of the passed bitmap), I >>> thought my >>> >> > goof could have been in my adaptation of the Mac version of that >>> code >>> >> > (http://codereview.chromium.org/108040/diff/2038/3040). But it >>> seems to >>> >> > be >>> >> > working fine if I disable the other part of that change (which is to >>> >> > paint >>> >> > only sub-rectangles in the bitmap). So if I paint a complete bitmap, >>> and >>> >> > pass it to the host with a list of sub-rectagles to draw... It >>> works... >>> >> > So I >>> >> > guess the goof is in the code that paint sub-rectangles in the >>> bitmap... >>> >> > But this code works fine on Windows and is not done in a Windows >>> >> > specific >>> >> > way... So I'm kind of lost and don't know where to look... Anybody >>> has a >>> >> > clue here? >>> >> >>> >> What's the problem that you see? >>> >> >>> >> Surely it could still be in the Mac specific code if you're painting >>> >> from the wrong regions in the bitmap? >>> >> >>> >> >>> >> AGL >>> > >>> > >>> > > >>> > >>> >>> >>> >>> -- >>> Mike Pinkerton >>> Mac Weenie >>> [email protected] >>> >>> >>> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
