Re: gtk_widget_set_double_buffered() is deprecated, so what can replace it?

[Lance Arsenault <lance arsenault gmail com>]

Hi  Emmanuele,

> apps using X11 to draw directly should stop doing that, because this is not 1997 any more, and we have better 
> drawing API.

Many many apps need a faster drawing API than Cairo in order to do high 
frame rate animations.  Interactive games is the most popular example.

I have an unusual app that requires faster drawing without animations.  
It's the difference between being able to use the app for some purposes 
or not, that is to say it's the difference between working and not 
working.   So Cairo is just not usable in this case, it's far to slow.  
Why should I care that libX11 is old?

This is not a small set of users that need this.  People don't care that 
the code is old, so long as it works for what we are doing.  Please 
consider that Cairo is too slow for many applications.  The largest 
group of apps that require fast drawing are openGL apps, but there is 
also a somewhat smaller group of apps that need faster 2-D drawing too.  
Cairo does not meet many minimum speed requirements.  I hear that 
GtkGLArea is coming of age.  I hope that I can use it for 2-D drawing 
too, but I will be sticking with libX11 drawing if that is faster than 
OpenGL for my use case, and I expect that drawing with libX11 will be 
faster for my use case.  (see below for more verbose with real runnable 
examples)

I got two responses from my query.   I attach more below.  I forgot to 
CC the list in the email I sent before this one.

cheers
lance



I'm not sure where this is going but I need to make sure I'm clearly 
understood.  Sorry for being too verbose. If you respond, please read it 
all.


1.  on Cairo speed:   I've spent many days testing Cairo for speed.  
Cairo draws lines very slowly compared to libX11 XDrawLines().  It does 
lots of nice things, but sometimes you just need to draw as fast as 
possible.  In the current app I'm developing I can't even use 
XDrawLines().  I use XDrawPoints() with my own line drawing code, and I 
use my own anti-aliasing code for some of the lines.

2.  The GtkGLArea 
<https://developer.gnome.org/gtk3/unstable/GtkGLArea.html> is news to 
me.  I will look into it.  Currently I'd like to use it to draw with 
libX11 and not directly with openGL given I'm just doing 2-D drawing 
with just point drawing.  It's a little unclear what the fastest simple 
2-D pixel drawing method is, because I see the X-server may be doing the 
right things already for fast 2-D drawing, i.e. I see it's using shared 
memory to get my pixels from my program, it links with OpenGL libs, and 
etc.  Sounds like way way more than I need, and it's likely to slow 
things down, compared to what I have now.  I'm also looking into 
libXrender, but know almost nothing about it yet.

3.  If you'd like to understand my perspective about drawing speed I 
have an example that explains it well when using a GNU/Linux system.  
Install quickplot (available on debian apt-get install quickplot) and 
run `quickplot LARGESOUNDFILE' where LARGESOUNDFILE is about a 3 minute 
sound file.  You will see quickplot display the whole sound file in 
about 3 seconds.   Running `quickplot -c LARGESOUNDFILE' takes about 15 
seconds to display.  That is because the '-c' option makes quickplot use 
Cairo to draw.  Of course back when I wrote quickplot using GTK+3.0 the 
difference was much more dramatic.  This may be a stupid example, but it 
makes my point, Cairo is slow.

4.  Now I'm making a software oscilloscope and 2-D drawing speed is 
paramount.  I see that in the GTK+3.0 code that there is Cairo code in 
gtk_widget_send_expose() that is adding system resource waste with 
gdk_cairo_create(), which I don't need, given I'm drawing with libX11 
and not Cairo.   This is not so bad, for this scope, given that most of 
the time the GTK+ "draw" event and its callbacks are not used in most of 
my draw display frames (just used in initial draws).  My code just draws 
over the X11 window without using GTK events, at like, for example, 60 
times a second.  This seems like a nasty hack.  Clearly if GTK+3.0 has a 
method to add animations I do not want to use it, given that it will do 
a bunch of Cairo stuff that I'll just want to work around it order to 
get the speed that I need.

5.   Optional:  If you got this far.   You can see for yourself what I'm 
up too and why GTK+3.0 needs to support fast 2-D drawing:

sudo apt-get install libsndfile-dev && # the prerequisite you may not have \
mkdir -p ${HOME}/tmp_quickscope && \
cd ${HOME}/tmp_quickscope && \
git clone https://github.com/lanceman2/quickscope.git && \
cd ${HOME}/tmp_quickscope/quickscope && \
./bootstrap && \
./configure --enable-debug --enable-tests --prefix 
${HOME}/tmp_quickscope && \
make -j3 && ./tests/alsaCapture

    I just successfully cut and pasted and ran that on my debian 
system, but you may not have all the prerequisites, also edit for other 
systems.   Key <q> to quit, <m> for menu.

    That will read and display sound that is coming into your 
microphone.  There are simpler non-ALSA examples that are in the tests 
that you can see with a simple launcher using `./tests/tests_launcher' 
.    If this works you'll be the first person, other then myself, to run 
this code.

    Please let we know if you try to run that.  I'll also try not to 
break the code with a new commit.

--lance


On 11/26/2014 02:00 PM, Emmanuele Bassi wrote:
> hi;
>
> On 26 November 2014 at 18:40, Lance Arsenault <lance arsenault gmail com> wrote:
> > Hello GTK developer,
> >
> > I've read the latest docs, looked at the latest (git) GTK+3 code, and
> > searched the archives, and found not direct answer to this question:
> >
> > 1.  Is there a method, that is not deprecated, that can give the effect of
> > gtk_widget_set_double_buffered() for GTK3?
> you can still call that function, but it's really not portable.
>
> > There are a lot of apps that must use the underlying/native drawing APIs
> > like libX11 and OpenGL to draw to a X11 window that is within a GTK+3.0 app.
> apps using X11 to draw directly should stop doing that, because this
> is not 1997 any more, and we have better drawing API.
>
> as for GL, you're lucky: GTK+ 3.16 will have OpenGL support by
> default, out of the box.
>
> ciao,
>   Emmanuele.