1. [wxEuphoria] making a "virtual window"
- Posted by DanM Feb 09, 2009
- 886 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?
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?
Dan
2. Re: [wxEuphoria] making a "virtual window"
- Posted by ghaberek (admin) Feb 09, 2009
- 870 views
See wxScrollingWindow. It should do what you're asking. Let me know if you find anything missing for it and I'll add it...
-Greg
3. Re: [wxEuphoria] making a "virtual window"
- Posted by ghaberek (admin) Feb 09, 2009
- 883 views
See wxScrollingWindow. It should do what you're asking. Let me know if you find anything missing for it and I'll add it...
Or is that wxScrolledWindow?
-Greg
4. Re: [wxEuphoria] making a "virtual window"
- Posted by mattlewis (admin) Feb 09, 2009
- 883 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).
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.
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
5. Re: [wxEuphoria] making a "virtual window"
- Posted by DanM Feb 09, 2009
- 893 views
See wxScrollingWindow. It should do what you're asking. Let me know if you find anything missing for it and I'll add it...
Or is that wxScrolledWindow?
-Greg
Well, that would be considerably easier, and it would seem to deal with the main reason I was
wanting to make the virtual window, namely reducing CPU load, but there's another issue
I was going to solve by using the virtual window: I want to only "auto-magically" scroll the text,
such that a timer or some such would cause the text to scroll, not have (or let) the user
scroll it themselves. I'm not sure, but I don't think there's any way to make the scroll bars
not visible but programmatically still make that window scroll?
So I may still need to be able to make a virtual window.
Dan
6. Re: [wxEuphoria] making a "virtual window"
- Posted by ghaberek (admin) Feb 09, 2009
- 869 views
Well, that would be considerably easier, and it would seem to deal with the main reason I was
wanting to make the virtual window, namely reducing CPU load, but there's another issue
I was going to solve by using the virtual window: I want to only "auto-magically" scroll the text,
such that a timer or some such would cause the text to scroll, not have (or let) the user
scroll it themselves. I'm not sure, but I don't think there's any way to make the scroll bars
not visible but programmatically still make that window scroll?
So I may still need to be able to make a virtual window.
Yeah... I think you're right.
-Greg
7. Re: [wxEuphoria] making a "virtual window"
- Posted by DanM Feb 09, 2009
- 839 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