No Subject

MIME-Version: 1.0
Subject: Re: Unidentified subject!
X-Authenticated-IP: []
Message-ID: <>
X-Mailer: WWW-Mail 1.5 (Global Message Exchange)
X-Flags: 0001
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit wrote:
> On Mon, Nov 22, 1999 at 02:37:46AM +0100, Antonio Campos wrote:
> > Certainly we have beaten Windows in a lot a questions, but the
> > smoothness of Windows is not only due to the graphics chipset (it's
> > an important factor obviously). I think that Windows is not using
> > GDI on a few applications. I think is really using DirectDraw to
> > write directly to video memory. If it is so, I don't like this way
> > of doing things, because DirectDraw is a focus of security problems
> > (no restrictions over who writes to video memory...).  Nevertheless,
> > I expect GTK to include double buffered widget in future releases...
> Don't forget that sometimes X programs are run over a network link.
> Smooth scrolling would be slow as hell if it has to be transfered over
> that, even if it's 100 BaseT ethernet. It doesn't matter *what* you
> use for graphics hardware in this case. And wouldn't double buffering
> be *slower* over a network link? If you use standard X calls, only the
> commands for those calls are transmitted, but if you use a buffer, you
> have to send every pixel in the region over the link, right?
> Pete
> --
>          To unsubscribe: mail with
>                        "unsubscribe" as the Subject.

Windows is using GDI in almost all applications! There was no
flickering, before DirectDraw also! In my opinion, Windows application
do not flicker mainly of two reasons:
        1) They are written accurately
        2) The Windows model (GDI) gives programers flexible ways to
The proposed in drawing
(begin/end_paint and so on) is something like the Windows model and it
is fine! But I do not believe in putting all of the flicker less drawing
in the library! Live to programers. For example: writing a Windows
application that uses ListView (an extended control similar to the Gtk's
CList control) you will have flickering if you just refill the ListView
every time! But the Windows Explorer right pane (that uses the ListView)
does not flickers on resizing and so on. What happens? The guys are
doing something like that (I have used it and it works) in every paint,
they tell the ListView to redraw itself, but in a back bitmap (Pixmap in
X terms). The pixmaps is cleared and refilled, but there is no
flickering, when you output the pixmap's contents on the screen!

I think it is possible in current release of Gtk to avoid flickering
using similar methods! We can set the window member of a widget to be a
pixmap and to output it to a real window only after the Pixmap is
redrawed. The problem is that widgets depend on their window member. So
another decision is to add in the draw method a parameter which is the
destination where the widget should be drawn and you can just call the
real draw with a pixmap and show that pixmap on the screen. This is my
suggestion for avoiding flickering. Please, do not try to solve the
problem using a general way! You will get a lot of other problems. Just
try to give careful programers a way to avoid flickering.

I am very happy to see such a discussion in this group, because I am
using both windows and Unix and EVERY Gtk application looks ugly
compared to its windows equivalent! The Graphic Interface is something
very important, but till yet there are no fine redrawing Unix programs.


Sent through Global Message Exchange -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]