Many thanks for the information Kimmo. At least I know which way to go now -
this seems to be similar to how iPhone apps behave and I guess this will allow
me to port to other OpenGL devices quite easily.
- Original message -
On Tue, 2009-12-29 at 16:17 +0100, Tamminen Eero
On Mon, 2010-01-11 at 18:58 +0100, Tamminen Eero (Nokia-D/Helsinki)
wrote:
Hi,
ext Frantisek Dufka wrote:
Recent
hildon-desktop versions disable compositing automatically for fullscreen
windows, unless you use HildonStackableWindow (which requires the
sliding animation).
I wonder
Hi,
ext Michael Cronenworth wrote:
Eero Tamminen on 12/30/2009 04:09 AM wrote:
Incorrect.
I guess there's some illegal black magic happening in-between compiz and
apps regardless of UI toolkit libraries. Apps such as dasher that
present rectangles and text at fast speeds do not present any
Kimmo Hämäläinen wrote:
Recent
hildon-desktop versions disable compositing automatically for fullscreen
windows, unless you use HildonStackableWindow (which requires the
sliding animation).
I wonder what happens to translucent information messages (charger
attached/removed, ...) in fullscreen
Hi,
ext Frantisek Dufka wrote:
Recent
hildon-desktop versions disable compositing automatically for fullscreen
windows, unless you use HildonStackableWindow (which requires the
sliding animation).
I wonder what happens to translucent information messages (charger
attached/removed, ...) in
On Tue, 2009-12-29 at 16:17 +0100, Tamminen Eero (Nokia-D/Helsinki)
wrote:
Hi,
ext Mark Clarkson wrote:
I have made a simple animation using a clutter timeline with
clutter-gtk-0.10 and clutter-1.0 but there is excessive tearing when the
animation plays making the animation look
Hi,
ext Michael Cronenworth wrote:
Eero Tamminen on 12/29/2009 09:17 AM wrote:
because Gtk doesn't have any support for Vsync.
Gtk doesn't need to support Vsync. Qt won't magically fix this problem
either.
Only the compositor needs to support Vsync. Once it does then *all* 2D
El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió:
This is not really
fixable due to how Gtk painting is arranged, parts of the window are
painted in application callbacks.
This is not totally correct. Application callbacks can only cause GTK+
to *invalidate* regions. In sane
Hi,
ext Claudio Saavedra wrote:
El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió:
This is not really
fixable due to how Gtk painting is arranged, parts of the window are
painted in application callbacks.
This is not totally correct. Application callbacks can only cause GTK+
On Wed, 2009-12-30 at 14:44 +0200, Eero Tamminen wrote:
Hi,
ext Claudio Saavedra wrote:
El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió:
This is not really
fixable due to how Gtk painting is arranged, parts of the window are
painted in application callbacks.
This is
Hi,
ext Xavier Bestel wrote:
But where inside the application process they happen (app or Gtk code)
is not so important. The issue is that Gtk (AFAIK) has no mechanism to
synchronize this drawing with the compositor and doesn't offer
applications any mechanism for it either. If
Eero Tamminen on 12/30/2009 04:09 AM wrote:
Incorrect.
I guess there's some illegal black magic happening in-between compiz and
apps regardless of UI toolkit libraries. Apps such as dasher that
present rectangles and text at fast speeds do not present any tearing
when I have the *compositor*
- Original message -
off on the *compositor*. My own apps are tear free until I turn off..
Ah. Is there some way that this will help me - the original poster? Does
clutter bypass the compositor by making its opengl calls? Do I need to somehow
render clutter output to an offscreen
On Wed, 2009-12-30 at 15:40 +, Mark Clarkson wrote:
- Original message -
off on the *compositor*. My own apps are tear free until I turn off..
Ah. Is there some way that this will help me - the original poster?
Does clutter bypass the compositor by making its opengl calls? Do
- Original message -
You could try playing with the CLUTTER_VBLANK env var (set it to none,
dri or glx) to see if it helps.
No joy with that one - makes no difference at all.
___
maemo-developers mailing list
maemo-developers@maemo.org
Eero Tamminen on 12/30/2009 04:09 AM wrote:
Is there some way that this will help me - the original poster?
Unfortunately, no. I have not, yet, investigated too far into the
compositor Nokia is using. My app references were to compiz, the
compositor found on most Linux desktop distributions.
Hi,
I have made a simple animation using a clutter timeline with clutter-gtk-0.10
and clutter-1.0 but there is excessive tearing when the animation plays making
the animation look terrible.
I have tried none, dri and glx values for the CLUTTER_VBLANK environment
variable but this seems to
Hi,
ext Mark Clarkson wrote:
I have made a simple animation using a clutter timeline with clutter-gtk-0.10
and clutter-1.0 but there is excessive tearing when the animation plays
making the animation look terrible.
I have tried none, dri and glx values for the CLUTTER_VBLANK environment
- Original message -
Is there a way to fix this?
Screen update isn't yet synched to LCD refresh. Please file a bug about
it to bugs.maemo.org (it needs support from kernel display driver, X
server, SGX driver, Clutter and hildon-desktop compositor, but I guess
you could file it
Eero Tamminen on 12/29/2009 09:17 AM wrote:
because Gtk doesn't have any support for Vsync.
Gtk doesn't need to support Vsync. Qt won't magically fix this problem
either.
Only the compositor needs to support Vsync. Once it does then *all* 2D
operations will be tear-free. Gtk, Qt,
20 matches
Mail list logo
