Re: Testing for drawing fixes r30523

[Doug Simons]

Quentin,

Did you have a chance to try this on Windows yet? We are stuck on moving forward with  any new updates in gui or back until this is resolved, which is not good.

Thanks,

Doug

On Jun 3, 2010, at 9:41 AM, Doug Simons wrote:

Quentin, thanks for working on this.

As a simple test, I tried commenting out these lines:

if (viewIsFlipped && (self

!= source))

   {

     destPoint.y -= sourceRect.size.height;

   }

That fixed the display of the image in the tableView, but introduced the same problem for all of the images of items in my toolbar: they were all shifted down and drawn with their tops in the same place as the item titles. So clearly a more sophisticated change is needed.

I tried a couple of other things without success, but it would take some time for me to wrap my head around what's going on here and really understand it, so at this point I'm just poking at things in the dark.

If you can get this running on Windows and make whatever adjustments it needs to work with your other recent changes, that would be greatly appreciated. Thanks!

Doug

On Jun 3, 2010, at 4:46 AM, Quentin Mathé wrote:

Hi Doug,

Le 2 juin 2010 à 21:36, Doug Simons a écrit :

This change has broken some things on Windows. Here is a screenshot from our application showing the problem, with an image displayed in a tableView (the table here contains only one row):

<Untitled Image.png>

When I roll back this change, it displays as it should:

<Untitled Image 2.png>

It's hard to tell from this particular image, but the image itself is not flipped, just displaced. Hopefully that's enough for you to tell what's going on. If you need additional information please let me know.

I think the backend is trying to compensate/revert an extra flipping previously done in Gui.
The code where the problem is located is -[Win32GState compositeGState:fromRect:toPoint:op:fraction:] pasted below.

The implementation looks similar to the old Cairo implementation, so the best way is probably to rewrite it in a similar way. That means I have to set up Windows somewhere since it's hard to get the implementation right. I don't have time today, but tomorrow I'll try to get a working GNUstep install on Windows to work on it.

By the way, does the scrolling still work on Windows?

if (viewIsFlipped && (self

!= source))

   {

     destPoint.y -= sourceRect.size.height;

   }

You can try to remove this part since the backend shouldn't need it now. But I I don't think it's enough to fix it.

 destRect.origin = destPoint;

 destRect.size = sourceRect.size;

 [ctm boundingRectFor: destRect result: &destRect];

The transform should be applied to destPoint only here.

 rectTo = GSWindowRectToMS(

self

, destRect);

 x = rectTo.left;

 y = rectTo.bottom - sourceRect.size.height;

 {

   NSRect newRect;

   [source->ctm boundingRectFor: sourceRect result: &newRect];

   rectFrom = GSWindowRectToMS(source, newRect);

   y += (sourceRect.size.height - newRect.size.height);

// adjust location for scaled source

The line before the last one looks dubious to me. To get it working properly in all cases (rotation, scaling, flipping etc.), I had to rewrite the Cairo backend to use a more complex check.

Thanks for feedback,
Quentin.


_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev