New XBoard alpha

[hgm]

So I would have to call Xlib directly to invalidate an area after drawing something on the memory buffer? And then in the expose handler look what area X11 asks me to redraw, and let cairo copy that part of the memory buffer to the drawable widget?

[Michel]

But if the toolkit is that smart, why should it burdon me with doing the buffering and then generating expose events? If it knows whether I am drawing from the program or the expose handler, it might as well have generated the expose events by itself when it knew I was drawing from the program.

Come to think of it, why should it require me to provide an expose handler in the first place? It could buffer any draw operation from the program in a buffer it allocated itself, and generate the corresponding expose events, which would call its own private expose handler the application programmer knows nothing about, which merely copies from the widgets private memory buffer to the screen.

GTK in general is fairly low level. But the DrawingArea cannot really know when is the right time to generate expose events (it cannot do this after every changed pixel).

You are probably more thinking of something like the canvas widget in tk (http://www.tkdocs.com/tutorial/canvas.html) which is a much higher structure than a DrawingArea in GTK but which does hide the burden of generating expose events from the user.

Non-rectangular regions would indeed make life easier. Note, however, that I am not using GTK, but only cairo. So far I have not been able to identify an 'invalidate region' call at all in cairo...

Ok. Cairo is just a drawing library. If the direct drawing worked in Xt then I guess it should still work with Cairo.

[kbhearn]

something along those lines. it appears x11 doesn't follow the invalidate procedure the same way as windows does though, but you could manually send an expose event with XSendEvent. i happen to like localising the code for drawing the entire internal data structure in one place rather than worrying how drawing in multiple places might interact weirdly, so it makes sense to me to have one routine that draws the board (or the necessary section of the board), and just call it from an expose event.

when talking about higher level libraries earlier i would've been referring to systems in libraries like qt and gtk that allow you to just setup a scene comprised of various images/shapes/etc and then the library handles all the actual rendering, so you don't wind up needing to worry about the differences between single buffering and double buffering, or which parts of the window need redrawing. These libraries tend to use a system where when you want things redrawn because of content changes you make a call to invalidate the window and force a redraw.

[Michel]

So I would have to call Xlib directly to invalidate an area after drawing something on the memory buffer? And then in the expose handler look what area X11 asks me to redraw, and let cairo copy that part of the memory buffer to the drawable widget?

I don't know how this should be done with pure Xlib and it does look a bit scary.... Trying to change the Xt code which has worked since forever is maybe also not such a good idea....

But when migrating to a modern toolkit it should be kept in mind.

[hgm]

Well, GTK and cairo might be low level, but of course XBoard is working therough the GenericPopUp. So it is easy as pie to attach a GenericExposeHandler to Graph widgets. In fact this is exactly what is already done, except that currently it passes expose events on to the user. And on creation of the widget, it returns a handle to the widget to the user.

I could in stead have it return a pointer to a cairo_surface_t of the proper size that it creates in memory , which the user could directly draw on, rather than making it the responsibility of the user to associate a bitmap to the widget. (It would do that too, but never let the user know about it.)

The GenericExposeHandler would then always copy the exposed area from the memory bitmap to the widget.

The only thing is that the drawing routines should trigger expose events.

[jshriver]

I tried building the cairo version and hitting the same issues.

annot stat `t-da.gmo': No such file or directory
make[3]: *** [da.gmo] Error 1


Any tips?

[hgm]

This anti-aliased vector graphics looks really nice. I wonder how I ever could have lived without it!



As it is now directly rendered from svg images (specified through the option -svgDirectory), there is now always maximum resolution at any board size. (A set of svg pieces is supplied with the source tar ball in the directory svg.)

And, most important for me: unorthodox pieces now available in any board size!

[ernest]

This anti-aliased vector graphics looks really nice. -)

Where do I find the corresponding version?

[hgm]

In the 'cairo' branch of my git repository.

[Michel]

Just a remark. To avoid problems the new svg directory probably should contain some author/copyright information (even though the files now implicitly fall under the GPL the original author retains his implicit copyright, unless he explicitly transfers it to someone else).

People at Debian worry about the copyright of artwork.