Re: More Windows stuff ... example gui apps work for me now
Am Donnerstag, 10.03.05 um 06:35 Uhr schrieb Nicola Pero: OK ... I did more Windows stuff ... I managed to build gnustep-base with all the additional libs (even if I didn't do any change to get this ... maybe because I'm installing different libs ?). I also got the gui working ... and generally libraries and bundles. I finally compiled some gui apps -- they work for me! I was pretty impressed with the gui apps :-) Anyway, the instructions I follow are starting to deviate a bit from the README.MinGW ... but they are quite simple, almost identical to the traditional Unix stuff. Here is what I do if you want to try it out -- I made this into a wiki page: http://mediawiki.gnustep.org/index.php/Installation_on_Windows thanks, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Drawing optimization question
On Mar 9, 2005, at 3:14 PM, Fred Kiefer wrote: Adrian Robert wrote: I'm drawing directly to a view, either using [NSString -drawAtPoint..] or, say, with NSRectFill() and friends. I do something like: [view lockFocus] (draw comands ...) [view unlockFocus] [[view window] flushWindow] ... Even [NSWindow flushWindow] will only flush the union of the rectangles it thinks some drawing was going on, but it guesses them based on lockFocusInRect:, if you locked the whole window, the whole window will be flushed. Thanks, I'll try lockFocusInRect:. This worked like a charm.. now X and my app are splitting the CPU equally ;) and performance is vastly improved. However, this raises the question, where did -lockFocusInRect: come from? Google shows a paltry 9 pages or so (these emails, when archives, will significantly increase this), all of which I read and none of which give any indication as to its origin. It's not in NeXT or OpenStep, nor is it in OS X. Also, what about the related method -unlockFocusNeedsFlush:? Are both of these just supposed to be for internal GUI use? In any case, it seems like a good system and well implemented. BUT.. if we wanted to implement what *Step/Cocoa does in determining the flush rectangle directly from the portion of the buffer that was modified by drawing, could this be done in GUI, or would it have to be done separately in each back-end? (Essentially every operation that modified the buffer would have to be wrapped by determine-rect-and-take-union.) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: More Windows stuff ... example gui apps work for me now
Nicola Pero wrote: OK ... I did more Windows stuff ... I managed to build gnustep-base with all the additional libs (even if I didn't do any change to get this ... maybe because I'm installing different libs ?). I also got the gui working ... and generally libraries and bundles. I finally compiled some gui apps -- they work for me! I was pretty impressed with the gui apps :-) Hi Nicola, if you enable the new building system for Cygwin as well, I could give it a try. No need for you to install a new Cygwin system just for that. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Drawing optimization question
Adrian Robert wrote: On Mar 9, 2005, at 3:14 PM, Fred Kiefer wrote: Adrian Robert wrote: I'm drawing directly to a view, either using [NSString -drawAtPoint..] or, say, with NSRectFill() and friends. I do something like: [view lockFocus] (draw comands ...) [view unlockFocus] [[view window] flushWindow] ... Even [NSWindow flushWindow] will only flush the union of the rectangles it thinks some drawing was going on, but it guesses them based on lockFocusInRect:, if you locked the whole window, the whole window will be flushed. Thanks, I'll try lockFocusInRect:. This worked like a charm.. now X and my app are splitting the CPU equally ;) and performance is vastly improved. However, this raises the question, where did -lockFocusInRect: come from? Google shows a paltry 9 pages or so (these emails, when archives, will significantly increase this), all of which I read and none of which give any indication as to its origin. It's not in NeXT or OpenStep, nor is it in OS X. Also, what about the related method -unlockFocusNeedsFlush:? Are both of these just supposed to be for internal GUI use? Yes, you are right. Living in the GNUstep world only, it took that method for granted. According to the changelog Adam added it back in 1999. In any case, it seems like a good system and well implemented. BUT.. if we wanted to implement what *Step/Cocoa does in determining the flush rectangle directly from the portion of the buffer that was modified by drawing, could this be done in GUI, or would it have to be done separately in each back-end? (Essentially every operation that modified the buffer would have to be wrapped by determine-rect-and-take-union.) From what I can tell we only used the rectangle that gets passed on to lockFocusInRect: for clipping (where we could as well use the view bounds) and for exactly that optimisation trick you benefit from. That is the line: [window_t->_rectsBeingDrawn addObject: [NSValue valueWithRect: wrect]]; This rectangle is later (on flush) merged with the rectangel needing flushing (window_t->_rectNeedingFlush). To become more similar to what Cocoa does, we could try, as you suggest, to keep track of which areas of a window we actually put ink on. But this looks a lot more complicated to me. One aspect that makes it difficult in GNUstep is that we have the separation between the window server and the graphics context in the backend. Drawing is done by the later, flushing by the former. We could try to compute the affected rect on the gstate, between the DPSgsave and the DPSgrestore call. It would be sufficent to do it once in GSGState, still this is a lot of work and a big change. I really would like a compatbible solution, but currently I am not seeing it coming soon. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
