On Sat, 2008-06-28 at 17:44 +0200, Patryk Zawadzki wrote:
The point is XRender is close to its
tenth birthday yet still no one seems to care.
Except that it's rendering your entire desktop the way you can't do
without it?
--
behdad
http://behdad.org/
Those who would give up Essential
On Sat, Jun 28, 2008 at 7:15 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote:
On Sat, 2008-06-28 at 17:44 +0200, Patryk Zawadzki wrote:
The point is XRender is close to its
tenth birthday yet still no one seems to care.
Except that it's rendering your entire desktop the way you can't do
without
Hi,
On Thu, Jun 26, 2008 at 11:43 AM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Metacity's compositor works pretty well here except for slow workspace
switching.
That should be addressed separately by switching from many-desktops
mode to small-viewport-over-a-large-desktop mode. Then you can
2008/6/27 Andrew Cowie [EMAIL PROTECTED]:
I've been very happy with stable and trunk Metacity with compositing
enabled, but the 2-3 second pause to redraw windows when changing
workspaces is really staggering.
Complain to the developers of your X driver to make their XRender faster.
I don't
David Zeuthen wrote:
Do you have a concrete example of a modern desktop application where the
absence of XSMP in GNOME 2.24 would be a huge inconvenience?
I think you should not limit yourself to GNOME 2.24; people are using
other applications.
Uh, I think you misread what I said.
Le jeudi 26 juin 2008, à 13:32 -0500, Diego Escalante Urrelo a écrit :
On 6/26/08, David Zeuthen [EMAIL PROTECTED] wrote:
On Thu, 2008-06-26 at 14:16 +0200, Rodrigo Moya wrote:
KDE applications are still using XSMP AFAIK, so we'll need to support
it in some way
We do? What happens
Get a better kernel then ;-). On a more serious note, didn't the recent
Firefox 3 O_SYNC fiasco on Linux make some file system developers
realize some short comings of current state of the kernel? If so,
Synchronous I/O is *very* slow but you need to discuss that mostly with
hardware vendors
On Fri, 2008-06-27 at 09:36 +0100, Alan Cox wrote:
That is why we have fsync/fdatasync and thread creation...
Yeah, if they were correctly implemented. But firefox fsync'ing its
sqlite db makes the whole system unusable for up to 20 seconds.
--
behdad
http://behdad.org/
Those who would
On Thu, 26 Jun 2008 16:02:24 -0600, Iain * [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 10:49 PM, Patryk Zawadzki [EMAIL PROTECTED]
wrote:
Nah, one thing about a compositor is that it keeps off-screen copies
of all the windows so it does not have to invalidate regions when the
stacking
Thanks for your email, I just asked yesterday morning Vincent about
the status of the dbus-based branch and this answers my questions.
William Jon McCann wrote:
I agree with that. Logout handling is broken too. The XSMP protocol
not only allows applications to be notified on logout (aka
On Wed, 2008-06-25 at 19:07 -0400, William Jon McCann wrote:
Hi,
Dan Winship and Lucas Rocha have done a nice job revamping the
gnome-session codebase. It was a meritorious task. You can read
about the design here:
http://live.gnome.org/SessionManagement/NewGnomeSession
What do you
On Thu, 2008-06-26 at 12:41 +1200, Callum McKenzie wrote:
On Thu, June 26, 2008 11:07 am, William Jon McCann wrote:
I don't think these are sufficient reasons to continue to solely rely
on XSMP. We can do these very well using D-Bus.
Can I assume from your use of the word solely that
Apropos, since we are talking about session management here: have you
guys ever thought of reuseíng upstart for managing session processes?
My thoughts exactly. We should at least talk to the upstart guys about
what code we can share.
___
I'm sorry if I missed something (I just woke up and my eyes and brain
aren't at 100% yet)...
Doing the startup in phases like that sounds to me to be suboptimal.
If we're halting the startup of a whole Desktop (or even Panel)
process just because we don't have a WM ready, it's going to add a lot
On Thu, Jun 26, 2008 at 3:43 PM, Alexander Jones [EMAIL PROTECTED] wrote:
* Currently, gnome-terminal starts up before the WM and if you run a
compositing WM, you get an RGB window unless you close it and open it
again.
That's because the gnome-terminal crew did an awesome job making sure
it
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an example. :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones:
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an example. :)
Guess Metacity's compositor needs to become much
On Thu, 2008-06-26 at 17:28 +0200, Patryk Zawadzki wrote:
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones:
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an
On Thu, Jun 26, 2008 at 5:37 PM, Jürg Billeter [EMAIL PROTECTED] wrote:
On Thu, 2008-06-26 at 17:28 +0200, Patryk Zawadzki wrote:
* replacing the current compositor with a GL-based one; or
Please don't. I really want compositing but I can't use a GL-based one
on all systems, as for example
Hi,
Jürg Billeter wrote:
I really want compositing but I can't use a GL-based one
on all systems, as for example even with some recent Intel desktop
mainboards you can't have DRI with a screen area larger than 2048x2048,
which is easily reached with two monitors.
I don't mean to be
Hi,
On Thu, 2008-06-26 at 17:55 +0200, Dave Neary wrote:
Jürg Billeter wrote:
I really want compositing but I can't use a GL-based one
on all systems, as for example even with some recent Intel desktop
mainboards you can't have DRI with a screen area larger than 2048x2048,
which is
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones:
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an example. :)
Guess Metacity's compositor needs to become much
On Thu, 2008-06-26 at 14:16 +0200, Rodrigo Moya wrote:
KDE applications are still using XSMP AFAIK, so we'll need to support
it in some way
We do? What happens if we decide not to?
David
___
desktop-devel-list mailing list
On Thu, Jun 26, 2008 at 6:25 PM, Iain * [EMAIL PROTECTED] wrote:
If you are one of those people with a crap graphics card (or drivers)
I have been working on getting a strange hybrid compositor working
that I'm assuming should be much faster
so that you can have simple compositing to give
On Thu, 2008-06-26 at 17:25 +0100, Iain * wrote:
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones:
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an example. :)
I don't mean to be impertinent, but isn't any screen bigger than
2048x2048 a major edge case? It's like desktop apps that only work on
screens bigger than 640x480... who cares at this stage? By the time
that's anything bug an edge case, won't the hardware have caught up?
It's far from an edge
On Thu, 2008-06-26 at 20:09 +0300, Karl Lattimer wrote:
I'm assuming you've turned on the appropriate xorg configuration
options to enable the correct acceleration
and none of that helped? I forget what they are, but I'm sure someone
will chime in.
ching
Section Extensions
On Thu, 2008-06-26 at 18:57 +0100, Ross Burton wrote:
On Thu, 2008-06-26 at 20:09 +0300, Karl Lattimer wrote:
I'm assuming you've turned on the appropriate xorg configuration
options to enable the correct acceleration
and none of that helped? I forget what they are, but I'm sure someone
On 6/26/08, David Zeuthen [EMAIL PROTECTED] wrote:
On Thu, 2008-06-26 at 14:16 +0200, Rodrigo Moya wrote:
KDE applications are still using XSMP AFAIK, so we'll need to support
it in some way
We do? What happens if we decide not to?
Tell them we are now using a better idea and that they
Am Donnerstag, den 26.06.2008, 17:55 +0200 schrieb Dave Neary:
Hi,
Jürg Billeter wrote:
I really want compositing but I can't use a GL-based one
on all systems, as for example even with some recent Intel desktop
mainboards you can't have DRI with a screen area larger than 2048x2048,
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Laptop with 1280x768 wides screen LCD plus external monitor or projector
with 1024x768 resolution gives 2304x768 pixels. This setup absolutely
doesn't look exotic for me, but requires more than 2048 horizontal
pixels. When writing this I am
On Thu, 2008-06-26 at 18:02 +0100, Alan Cox wrote:
It's far from an edge case. Any situation with two monitors side by side
of 1024 pixel width causes the problem. Thats a pretty normal setup for
anyone doing art design, engineering or similar work.
Indeed.
(And yes I agree the
Am Donnerstag, den 26.06.2008, 17:25 +0100 schrieb Iain *:
2008/6/26 Mathias Hasselmann [EMAIL PROTECTED]:
Am Donnerstag, den 26.06.2008, 15:28 +0100 schrieb Alexander Jones:
Agreed, we need to move towards expecting Composited as default and
Direct as a niche case, but this was just an
On Thu, Jun 26, 2008 at 6:13 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
I'd say for me the only essential feature of a compositor is not
watching the goddamn windows redraw each time you switch apps and
workspaces.
Then you don't need a compositor
Turn it off. problem solved.
On Thu, Jun 26, 2008 at 6:09 PM, Karl Lattimer [EMAIL PROTECTED] wrote:
Have you looked at xcompmgr? it might be a good starting point. I have
somewhere a hacked up version of xcompmgr which has some extra features.
Let me know if you'd like it.
Good idea, wish I'd thought of that first...
David Zeuthen wrote:
KDE applications are still using XSMP AFAIK, so we'll need to support
it in some way
We do? What happens if we decide not to?
Yes we do; at least I believe so. I won't complain about my xterms as
they may be considered a legacy application but modern applications
On Thu, Jun 26, 2008 at 11:41 PM, Iain * [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 6:13 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
I'd say for me the only essential feature of a compositor is not
watching the goddamn windows redraw each time you switch apps and
workspaces.
Then you
On Thu, Jun 26, 2008 at 10:49 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Nah, one thing about a compositor is that it keeps off-screen copies
of all the windows so it does not have to invalidate regions when the
stacking order changes.
To be totally honest, I've never really thought of that
On Thu, 2008-06-26 at 12:40 -0400, David Zeuthen wrote:
On Thu, 2008-06-26 at 14:16 +0200, Rodrigo Moya wrote:
KDE applications are still using XSMP AFAIK, so we'll need to support
it in some way
We do? What happens if we decide not to?
well, we'll get tons of bug reports about KDE apps
William Jon McCann wrote:
Hi,
Dan Winship and Lucas Rocha have done a nice job revamping the
gnome-session codebase. It was a meritorious task. You can read
about the design here:
http://live.gnome.org/SessionManagement/NewGnomeSession
The new code is much cleaner. Parts of the new design
On Thu, 2008-06-26 at 23:02 +0100, Iain * wrote:
On Thu, Jun 26, 2008 at 10:49 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Nah, one thing about a compositor is that it keeps off-screen copies
of all the windows so it does not have to invalidate regions when the
stacking order changes.
On Thu, 2008-06-26 at 23:02 +0100, Iain * wrote:
On Thu, Jun 26, 2008 at 10:49 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Nah, one thing about a compositor is that it keeps off-screen copies
of all the windows so it does not have to invalidate regions when the
stacking order changes.
On Thu, 2008-06-26 at 23:46 +0200, Frederic Peters wrote:
Yes we do; at least I believe so. I won't complain about my xterms as
they may be considered a legacy application but modern applications
written for the other major free desktop should not be left in the
cold.
Do you have a concrete
On Fri, Jun 27, 2008 at 12:08 AM, Bastien Nocera [EMAIL PROTECTED] wrote:
I think Patryk was thinking more of the case where the application
hangs and doesn't redraw. Which looks really bad. Compositors fix
that.
Exactly - that's the most common scenario - app X is bound to IO and
it won't
On Thu, Jun 26, 2008 at 11:34 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Exactly - that's the most common scenario - app X is bound to IO and
it won't receive redraw requests until another app stops trashing the
disk.
I'd suggest that thats a broken application that should be fixed,
rather
On Fri, Jun 27, 2008 at 12:51 AM, Iain * [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 11:34 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Exactly - that's the most common scenario - app X is bound to IO and
it won't receive redraw requests until another app stops trashing the
disk.
I'd
David Zeuthen wrote:
Yes we do; at least I believe so. I won't complain about my xterms as
they may be considered a legacy application but modern applications
written for the other major free desktop should not be left in the
cold.
Do you have a concrete example of a modern desktop
On Thu, Jun 26, 2008 at 11:59 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote:
Well even if you try to read just a 10k file you can get stuck if
another application is causing excessive IO (and I tend to run such
applications). It's hard to delegate each disk operation to a separate
thread just
On Fri, 2008-06-27 at 01:08 +0200, Frederic Peters wrote:
David Zeuthen wrote:
Yes we do; at least I believe so. I won't complain about my xterms as
they may be considered a legacy application but modern applications
written for the other major free desktop should not be left in the
On Fri, 2008-06-27 at 00:59 +0200, Patryk Zawadzki wrote:
Well even if you try to read just a 10k file you can get stuck if
another application is causing excessive IO (and I tend to run such
applications). It's hard to delegate each disk operation to a separate
thread just in case the
On Fri, 2008-06-27 at 00:05 +0200, Rodrigo Moya wrote:
of course, instead of supporting XSMP, we could try to get KDE use
William's new implementation
Even that will take time. They still have a lot of work to finish
porting apps to KDE4[1]. So while this is a good idea, it should be made
sure
I've been very happy with stable and trunk Metacity with compositing
enabled, but the 2-3 second pause to redraw windows when changing
workspaces is really staggering.
On Thu, 2008-06-26 at 17:43 +0200, Patryk Zawadzki wrote:
Metacity's compositor works pretty well here except for slow
On Wed, 25.06.08 19:07, William Jon McCann ([EMAIL PROTECTED]) wrote:
We can still support applications that only know if they should
inhibit just in time by emitting a signal when a logout is
requested. The applications can then take an inhibit in response to
that signal.
This part sounds
On Thu, 2008-06-26 at 01:45 +0200, Lennart Poettering wrote:
On Wed, 25.06.08 19:07, William Jon McCann ([EMAIL PROTECTED]) wrote:
We can still support applications that only know if they should
inhibit just in time by emitting a signal when a logout is
requested. The applications can
On Wed, 25.06.08 19:49, David Zeuthen ([EMAIL PROTECTED]) wrote:
On Wed, 2008-06-25 at 19:07 -0400, William Jon McCann wrote:
What do you think?
Definitely +1 from me. The proposal is well thought out and you've done
your research/homework. Plus it builds upon and uses well-understood and
Hey Lennart,
On Wed, Jun 25, 2008 at 7:45 PM, Lennart Poettering [EMAIL PROTECTED] wrote:
On Wed, 25.06.08 19:07, William Jon McCann ([EMAIL PROTECTED]) wrote:
We can still support applications that only know if they should
inhibit just in time by emitting a signal when a logout is
On Wed, 25.06.08 20:00, William Jon McCann ([EMAIL PROTECTED]) wrote:
Hey!
We can still support applications that only know if they should
inhibit just in time by emitting a signal when a logout is
requested. The applications can then take an inhibit in response to
that signal.
This
On Thu, 26.06.08 00:48, Bastien Nocera ([EMAIL PROTECTED]) wrote:
On Thu, 2008-06-26 at 01:45 +0200, Lennart Poettering wrote:
On Wed, 25.06.08 19:07, William Jon McCann ([EMAIL PROTECTED]) wrote:
We can still support applications that only know if they should
inhibit just in time
On Wed, 2008-06-25 at 19:49 -0400, David Zeuthen wrote:
Most importantly, I think, this is a
good example of progress in GNOME via
the JFDI school of thought.
That is *exactly* what I was thinking when I read Jon's email.
Well thought out indeed.
AfC
Sydney
signature.asc
Description: This
On Thu, June 26, 2008 11:07 am, William Jon McCann wrote:
I don't think these are sufficient reasons to continue to solely rely
on XSMP. We can do these very well using D-Bus.
Can I assume from your use of the word solely that your
backwards-compatibility strategy is to leave XSMP support in
Is there any way of allowing applications to prompt the user for
something before exiting as part of this process? Firefox at the least
likes to ask about saving session before quitting, and some other apps
(gnome-terminal for one) might like to ask if you're sure since you
have multiple tabs
61 matches
Mail list logo