Re: GUI/back changes in CVS
Fred Kiefer wrote: Fred Kiefer wrote: What I was planning to do was add a simple (and of course slow) pattern drawing mechanism for the gsc classes and perhaps overwrite this with a faster one for the xlib backend. [snip] [colour_pattern compositeToPoint: NSMakePoint(x, y) operation: NSCompositeSourceOver]; I think this should be -drawToPoint:fromRect:operation:fraction: in order to handle transformations correctly; would have to check the PLRM to be sure about pattern semantics, though. [snip] All of this works fine. Of course EOFill is currently not supported, but simple to do (would require a call to DPSeoclip instead of DPSclip). And the clipping is what stops me from merging this code into CVS. As I need to change the clipping, and restore it afterwards, I could either implement this separately for each backend and not share any code or implement that clipPath method, used in the current implementation, for all backends. As this method is also not that easy, I could fake it by storing the current clip path in another slot of the GState (and keep the EO state within this path, as we need that as well when reseting the old clip). But perhaps somebody out there has a better idea for this? PSgsave/PSgrestore are the only portable methods for saving and restoring the clipping path, and I'd suggest using those. The current clipping path is the intersection of all paths passed to PSclip/PSeoclip (since the path was last reset, etc.; also, note that the filling rule merely specifies how the path to be intersected with the clipping path should be interpreted, the clipping path doesn't have any such property), so for a backend to be able to return the clipping path as an actual path, it would have to be able to compute arbitrary bezier curve intersections, and that's a nasty problem. - Alexander Malmberg ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
Hi Alexander, thank you for that feedback and more important: Great to have you back here! Your comment on PSGsave and PSGrestore is correct. The problem here is that we only know in the GState that we are going to draw a pattern image, while the PSGsave and PSGrestore operations should be applied on the context level. Not sure, if we should decorate every fill operation with a save/restore combination. You are propably correct about the drawToPoint call. Its just that this fails on xlib sometimes that I didn't want to use that method, Cheers Fred Alexander Malmberg wrote: Fred Kiefer wrote: Fred Kiefer wrote: What I was planning to do was add a simple (and of course slow) pattern drawing mechanism for the gsc classes and perhaps overwrite this with a faster one for the xlib backend. [snip] [colour_pattern compositeToPoint: NSMakePoint(x, y) operation: NSCompositeSourceOver]; I think this should be -drawToPoint:fromRect:operation:fraction: in order to handle transformations correctly; would have to check the PLRM to be sure about pattern semantics, though. [snip] All of this works fine. Of course EOFill is currently not supported, but simple to do (would require a call to DPSeoclip instead of DPSclip). And the clipping is what stops me from merging this code into CVS. As I need to change the clipping, and restore it afterwards, I could either implement this separately for each backend and not share any code or implement that clipPath method, used in the current implementation, for all backends. As this method is also not that easy, I could fake it by storing the current clip path in another slot of the GState (and keep the EO state within this path, as we need that as well when reseting the old clip). But perhaps somebody out there has a better idea for this? PSgsave/PSgrestore are the only portable methods for saving and restoring the clipping path, and I'd suggest using those. The current clipping path is the intersection of all paths passed to PSclip/PSeoclip (since the path was last reset, etc.; also, note that the filling rule merely specifies how the path to be intersected with the clipping path should be interpreted, the clipping path doesn't have any such property), so for a backend to be able to return the clipping path as an actual path, it would have to be able to compute arbitrary bezier curve intersections, and that's a nasty problem. - Alexander Malmberg ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
Adrian Robert wrote: On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: I just added changes to GUI and back that will in the end allow pattern images for GNUstep and the new MacOSX composite operator that uses an addtional alpha value. I wanted these changes to go into the next release as this will break binary compatibility between GUI and back. I have tested this change with xlib. It would be great, if somebody could test it before the release with art and winlib. Is there an easy way to test it? Is there something in the new test suite that exercises this facility? Here is the simple application I tested with. But I am not even sure if the different operators have been implemented correctly for xlib, but thenm only one of the images I use has alpha values. Perhaps I should test with to transparent images. composite.tgz Description: application/compressed-tar ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
Nicolas Roard wrote: On 7/11/05, Fred Kiefer [EMAIL PROTECTED] wrote: Adrian Robert wrote: On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: I just added changes to GUI and back that will in the end allow pattern images for GNUstep and the new MacOSX composite operator that uses an addtional alpha value. I wanted these changes to go into the next release as this will break binary compatibility between GUI and back. I have tested this change with xlib. It would be great, if somebody could test it before the release with art and winlib. Is there an easy way to test it? Is there something in the new test suite that exercises this facility? Here is the simple application I tested with. But I am not even sure if the different operators have been implemented correctly for xlib, but thenm only one of the images I use has alpha values. Perhaps I should test with to transparent images. This test is only for composition, but what about the pattern images ? The filling patterns you are talking about, is setting an image to a color and then fill something with this color, right ? I'm asking because when I profiled Camaelon, pattern filling was one of the thing that took lots of time, and i'm hoping that by having the possibility to use filling pattern directly it will be faster (as you shouldn't need context switching during the filling). And, does it properly follow the current path mask ? (actually I think that doesn't work on xlib, only with art, anyway...) Sorry, some things seem to have gotten mixed here. I wrote that in the end this will allow pattern images. They are not already there after the first patch. Support for pattern colours requires two steps in the backend: It needs to know, which image pattern to use, which is what I implemented (the result of a pattern colour set command). And it needs to draw this image, when a fill operation happens. I did not even work on this second bit. Now art has an implementation of the very powerfull shfill PS command. This allows, amongst other things, a pattern fill. So here the second bit is already persent, while the first bit was missing. It should be rather simple to implement full pattern colours drawing for the art backend now. But this is nothing I am planning to do. The whole structure of the art backend is very foreign to me. I don't dare to touch anything here, because I may easily break things in an environment that is so contrary to the way I normally program. What I was planning to do was add a simple (and of course slow) pattern drawing mechanism for the gsc classes and perhaps overwrite this with a faster one for the xlib backend. Perhaps you could add the art pattern fill bit and I provide the rest? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
On 7/11/05, Fred Kiefer [EMAIL PROTECTED] wrote: Adrian Robert wrote: On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: I just added changes to GUI and back that will in the end allow pattern images for GNUstep and the new MacOSX composite operator that uses an addtional alpha value. I wanted these changes to go into the next release as this will break binary compatibility between GUI and back. I have tested this change with xlib. It would be great, if somebody could test it before the release with art and winlib. Is there an easy way to test it? Is there something in the new test suite that exercises this facility? Here is the simple application I tested with. But I am not even sure if the different operators have been implemented correctly for xlib, but thenm only one of the images I use has alpha values. Perhaps I should test with to transparent images. This test is only for composition, but what about the pattern images ? The filling patterns you are talking about, is setting an image to a color and then fill something with this color, right ? I'm asking because when I profiled Camaelon, pattern filling was one of the thing that took lots of time, and i'm hoping that by having the possibility to use filling pattern directly it will be faster (as you shouldn't need context switching during the filling). And, does it properly follow the current path mask ? (actually I think that doesn't work on xlib, only with art, anyway...) Thanks, -- Nicolas Roard Any sufficiently advanced technology is indistinguishable from magic. -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: I just added changes to GUI and back that will in the end allow pattern images for GNUstep and the new MacOSX composite operator that uses an addtional alpha value. I wanted these changes to go into the next release as this will break binary compatibility between GUI and back. I have tested this change with xlib. It would be great, if somebody could test it before the release with art and winlib. Is there an easy way to test it? Is there something in the new test suite that exercises this facility? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
