Re: [wxEuphoria] making a "virtual window"
- Posted by DanM Feb 09, 2009
- 838 views
I'm trying to modify the demo "text-on-window" such that ALL the text would be written to a "virtual window" first; that way, the arrow-keys, instead of constantly re-writing portions of text from the read-in file to the window, could make relevant portions of the virtual window be blitted to the real window, so as to have a moving "view-port".
First, I moved the "TextFrame = create( wxFrame..." up higher in the demo (just so I could see it better), which worked ok, and then added "canvasBMP = create( wxBitmap, {BM_IN_MEMORY, ScrnDim[1], ScrnDim[2]})," with the intent to write the text TO that bitmap.
But should I also create a "wxMemoryDC", as in "trans_blit.exw" demo?
Yes. The wxMemoryDC is what you'll need to use to pass to any routine asking for a DC (wx_puts(), etc).
ok, I think I understand that now.
And can I CHANGE the virtual window's size via "set_size" after the text file is loaded & length/height can be determined, so it can hold all the text?
No. The bitmap isn't actually a window. If you need something bigger, then you should delete the old one and its wxMemoryDC (to prevent memory leaks) and create a new, bigger bitmap.
Ok, then what I think I'll try is to get the file in before creating the bitmap and its associated wxMemoryDC, so I can try to see how big it needs to be. I did use a setCtlSize on a Win32Lib Virtual screen, seemed to work ok, but now I have to wonder if I might have been generating memory leaks there. Not sure how I would check that, though.
Having said all that, I'd recommend taking a look at the text-on-window.exw demo. It's really just a port of a similar Win32Lib demo that allows you to scroll around the source of the demo. It draws directly to the screen, and generally seems pretty snappy. Are you sure you need to have the entire thing in there?
Note that I'm not arguing against double buffering, since that is useful to reduce flicker. I'm just wondering if you're going to a lot of effort for little effect.
Matt
Well, its the text-on-window.exw demo that I'm trying to modify, as a starting point. And what I noticed is that when it processes some of the text to color in the beginning of the list, it takes a significantly higher percentage of cpu time, and the routines that I would use to write to the screen might be even more cpu intensive, so I figured that if I wrote it once, to a bit map virtual screen, rather than directly to the screen on every paint event, and just blitted the virtual screen over, then that would be better from cpu use perspective. I looked at the trans-blit demo, and it doesn't use as much cpu, though it's a very small pic that's blitted, don't know how much difference that would make.
But you're right, if there's an easier way, I'd prefer easier!
Dan
