I solved it. It IS possible to emulate that desirable behaviour of the wxStaticBitmap. :) If you paint to the same place every time, the pixels are not repainted unless they need to be. So I can make a huge bitmap sized panel as child to the client-area-sized panel, and use Move() on the big one, just as I did with the bitmap.
I tried using GetSubBitmap as an experiment and it failed as before. While the peices CAN be snagged and drawn as fast as scrolling a large single one, this is only true in Windows 98 (and presumably any system) if there is enough memory. It really doesn't matter how many fragments I cut and collage together, if the total client size to be drawn is big enough that fast redraws threaten to use something up. Even if I delete each bitmap fragment and wxRect or whatever as I go along, it stutters and freezes within moments after a fast start. And anyway, you MUST have one big bitmap to start with, to get sub bitmaps from, so if the system isn't loading that it's game over anyway, so loading one big one is best, just do it sparingly and make manipulations as few, simple and direct as possible. Regarding layers, I've managed to reduce to two, the input control layer and the vector draw layer are the same, over a chart layer. While that has two panels they are parent and child, only two panels have the same parent (the frame) and overlap in equal size and position. I don't know what this means, 'overlapping windows not supported'. From what I've seen the behaviour is constent and has been for all the versions of wxLua I've tried, I think. Considering it works to solve significant drawing problems, maybe it should be supported! Something that useful ought to be explored, exploited, and guarded against future changes breaking it. John, what platform do you use? I guess when you ran my examples and saw them work, at least as described, it suggests it's not only workable on W9X. And if you're using Linux it surely implies it's based on something deep and determined in wxWidgets or wxLua, whether nominally supported or not. I still use that OnPaint function to do the vector drawing. (Clipped to only visible area, as I thought was already clear). I know you said I ought to stop it from calling OnPaint every time the chart was moved around, but I don't agree, it's crucial to the way it works that it is done this way. And it DOES work, cleanly, in more than one version now that I emulated that wxStaticBitmap behaviour from the earlier version. I think the more basic the methods I use, the less likely it is to suffer borkage with further changes too. Lastly, I stress again that the wxScrolledWindow really didn't work well. It was a good example of how using elaborate self-contained tools with parts I can't control is a good way to always be fighting with the system instead of using it. Jittering images during mouse-grab scrolling and weird unstoppable mousewheel events were just a part of that one, if I'd stayed with it I might have found more instead of discovering far more useful ways to use basic controls and methods common to most wxWindows. I have more freedom this way, and likely more security against changes too. Now, if I could build my own SpinControls... :) But that might be overplaying the hand. > >On Mon, Jun 1, 2009 at 6:11 PM, lostgallifreyan ><lostgallifre...@gmail.com> wrote: >> >> I know, that's why I just sent the post I sent just before I found this one >> of yours. It contains full context so no further circles of guessing are >> needed. It's taking too much time to reduce to contextless samples so this >> is as good as I can get it. I need to know if it's only working because of >> some bug that happens to favour it, or if there's a proper way to get the >> same results. >> > >I ran the code and I see that the EVT_PAINT handler is incessantly >called when you scroll over and down a bit. I would guess that is >because you have overlapping windows which is not supported by >wxWidgets. Before you can make any headway you have to get it to stop >doing that. Put a print(os.date()) statement in the EVT_PAINT handler >to see what I mean. > >I suggest trying to use a single wxWindow to do all the drawing and to >clip the bitmap and lines to only draw the visible portions. You can >even use a wxScrolledWindow if you like to make it more obvious to the >user that they can scroll around. > >Regards, > John > >------------------------------------------------------------------------------ >OpenSolaris 2009.06 is a cutting edge operating system for enterprises >looking to deploy the next generation of Solaris that includes the latest >innovations from Sun and the OpenSource community. Download a copy and >enjoy capabilities such as Networking, Storage and Virtualization. >Go to: http://p.sf.net/sfu/opensolaris-get >_______________________________________________ >wxlua-users mailing list >wxlua-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/wxlua-users ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
