graphics updating

[xor0]

Hi,

I am doing a project using xWin. I have a main loop where state
variables are updated. Within this loop a call is made to a graphics
function to output an image of the variables. The problem is that the
graphics do not update until the loop has finished running, rather
than at each time step. In fact even if I take the graphics code from
the function and put it directly into the main loop it still does not
update until the loop has finished.

I don't see a way on this page to upload my program file, it's too
long to paste here. Does this problem seem familiar to anyone? Any
solution?

[Guy1954]

Hi Paul,

What is xWin? Is it WinX?
You can zip your Xblite program source and attach it to a message.
You can even "Private eMail" me in this Group if you don't want your
message public.
Probably, I can help you only if I can run your code.
So, send it to me especially if you use a viXen project.
In that case, send me the project AND the modified source.

Bye! Guy

[xor0]

WinX, yes, sorry. There isn't an attachment option here so I'll email
you the code. It seems to try to display everything at the end instead
of one frame per iteration, a buffer flushing issue?

[Callum Lowcay]

I took a peek at my old source code, and I think you need to call WinXUpdate
to redraw the window.

[xor0]

Yes I've been using WinXUpdate to draw the window and it's been
working fine, until I try to call the graphics routine from a loop.
Then it doesn't matter if I call WinXUpdate twice, from the graphics
routine or the loop, it doesn't start drawing til the loop has
finished.

Thanks very much for WinX by the way. It's a fantastic resource.

[Callum Lowcay]

Aha, got it. Your loop is interfering with the MS Windows event loop. All
Windows applications have an event loop where they poll for events, and a
"window procedure" function that handles the events. WinX hooks into this
system so you don't see the raw events. The whole thing is single threaded,
largely because there was no such thing as multithreading when it was invented
in the 80's.

Drawing only happens when the window receives a WM_PAINT event. WinXUpdate is
responsible for sending that event.

Long story short, while your loop is running, the Windows event loop is not.
If the event loop is not running, the WM_PAINT event does not get dispatched,
and nothing gets drawn.

I think WinX is the wrong tool for the job here. If you're drawing in a loop
you probably want SDL or OpenGL. OpenGL can be set up for 2D graphics, and it
is good for lines and shapes. SDL just gives you a framebuffer, which is good
for bitmaps. There are XBlite bindings for both libraries, and there should
be a few examples lurking around too.

[jo s.]

It is waiting for the WM_PAINT event
I use this workaround, I write in the memory and over the screen at
the same moment
When the pixel in the screen will be deleted by another superimposed
object or win resize event, the PAINT event swap his pixel
I hope help you, my english is bad

example:
CASE $$Menu_File_EditFile :
mydc=GetDC(hWnd)
SetPixel(mydc,pointX-xCurrentScroll,pointY-yCurrentScroll,0xFFFFFF)
ReleaseDC(hWnd,mydc)
' and also.....
hdc=BeginPaint(hWnd,&ps)
hdcMem=CreateCompatibleDC(hdc)
SelectObject(hdcMem,hBmp)
SetPixel(hdcMem,pointX,pointY,0xFFFFFF)
BitBlt(mydc,0,0,bmp.width,bmp.height,hdcMem,0,0,$$SRCCOPY)
DeleteDC(hdcMem)
EndPaint(hWnd,&ps)

2012/2/10 Callum Lowcay <cal...@callumscode.com>:

[David Szafranski]

You can use double buffering techniques and also modify the message loop
so that you are always updating the window when not processing messages.

See the screen saver demo called balls.x. It is found in the \demo\gui\balls\
folder. It should give you the basic idea of how this works.

D.

--
You received this message because you are subscribed to the Google Groups "xblite" group.
To post to this group, send email to xbl...@googlegroups.com.
To unsubscribe from this group, send email to xblite+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xblite?hl=en.

[Paul Bush]

Thanks for all the advice people. I decided to go with GLFW, an API for OpenGL, which uses double buffering and an open event loop. It only allows one window at a time so my project is now a WinX/OpenGL hybrid, but it runs nice and fast!

---

Date: Sun, 12 Feb 2012 20:35:50 -0800
Subject: Re: [xblite] graphics updating
From: david.sz...@gmail.com
To: xbl...@googlegroups.com