gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: supportsDrawGState


From: Quentin Mathé
Subject: Re: supportsDrawGState
Date: Tue, 14 Jun 2011 13:14:22 +0200

Le 13 juin 2011 à 21:37, Fred Kiefer a écrit :

> On 13.06.2011 20:19, Quentin Mathé wrote:
>> Le 13 juin 2011 à 14:41, Fred Kiefer a écrit :
>> 
>>> I had to restrict the usage of the new image drawing mechanism for
>>> the cairo backend to the cases where the clipping region is
>>> representable as a list of rectangles. With the new drawing code we
>>> store and restore the GState and this only works correctly when the
>>> clipping region is composed of rectangles.
>> 
>> I don't see where the gstate is saved/restored in the new drawing
>> code and not in the old code path. I checked both Back and  Gui.
>> Which lines are you referring to precisely? In Back cairo_save() and
>> cairo_restore() seems to be used in both cases. On the Gui side,
>> PSgsave(), DPSgsave(), PSgrestore() or DPSgrestore() seems to be used
>> in the same way in the two drawing methods.
>> 
>>> The problem became obvious in the JigSaw Application which is now
>>> part of GAP and which does use non-rectangular shapes for its
>>> pieces. These pieces where drawn incorrectly with the new drawing
>>> mechanism but correctly with the old one.
>> 
>> Are they drawn correctly on Mac OS X?
>> 
>>> I would love to see a better solution for this, so feel free to
>>> suggest one.
>> 
>> Agreed :-)
> 
> Quentin,
> 
> I would have expected a little trust in my analysis here :-)

I just wanted to understand your analysis, because I was unable to :-) Sorry if 
the way I put it was a bit rude.

The other thing is that I prefer to be very cautious with anything that is 
related to -compositeGState: in the Cairo backend. Although I understood this 
code when I rewrote it. I must admit I would have troubles to understand the 
details now.

> But anyway you are free to ask and not just take my word for it. The
> difference is between the methods guiDrawInRect:... and
> nativeDrawInRect:... If you carefully count the PSgsave calls you will
> see that each has exactly one in each call path. The difference is that
> in guiDrawInRect:.. the save happens while drawing on the cache surface
> whereas for nativeDrawInRect:.. we use the save while drawing on the
> main surface. This may look only slightly different but changed the whole 
> thing.

ok, I see the problem.

> The annoying bit here is that we now know that we have a general problem. For 
> this image drawing issue I was able to resolve it, but if somebody manually 
> sets a non rectangular clip and than uses PSsave we are in trouble.

Before Eric's composite rewrite two months ago or so, there was no DPSgsave() 
and DPSrestore() around the final drawing code in -nativeDrawInRect:… see 
http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Source/NSImage.m?revision=32434&view=markup
Unless I'm overlooking something, a possible solution could be:

    //NSLog(@"Draw in %@ from %@ from cache rect %@", 
NSStringFromRect(dstRect), 
    //  NSStringFromRect(srcRect), NSStringFromRect(srcRectInCache));

   NSAffineTransform *currentCTM = [ctxt GSCurrentCTM]; <--- rather DPSsave()

    transform = [NSAffineTransform transform];
    [transform translateXBy: dstRect.origin.x yBy: dstRect.origin.y];
    [transform scaleXBy: dstRect.size.width / srcRectInCache.size.width
                    yBy: dstRect.size.height / srcRectInCache.size.height];
    [transform concat];

    [ctxt GSdraw: gState
         toPoint: NSMakePoint(0,0)
        fromRect: srcRectInCache
       operation: op
        fraction: delta];

    [ctxt GSSetCTM: currentCTM]; <--- rather DPSrestore()

    [ctxt GSUndefineGState: gState];
    DESTROY(cache);

What do you think?

Cheers,
Quentin.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]