Subject: Re: Bug#98091: that's not good enough

From: Zack Weinberg <[email-masked]>
Date: Wed, 9 Jan 2002 00:03:29 -0800

On Tue, Jan 08, 2002 at 09:07:52PM -0500, Dan Espen wrote:
> > 
> > Correctness (cooperative X client behavior, in this case) is more
> > important than performance.  And I strongly suspect that outline moves
> > can be implemented without grabbing the server but still faster than
> > opaque moves.
> 
> I'm pretty sure you're right, there probably could be an outline
> move without a grab that would perform somewhere between
> the current xor-move and the opaque move.

I wish I knew more about X11 programming, then I would try to
implement something myself.  Handwaving wildly - could you somehow
intercept updates to any of the windows under the outline, and re-xor
those pixels against the outline?

> If I remember, one of the complaints about the server grab is
> that xmms stopped playing.

That was the easiest-to-reproduce example I could think of.

> You might consider filing a bug report with the xmms folks.

Not a bad idea...

zw

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Tue, 08 Jan 2002 21:07:52 -0500

Zack Weinberg <[email-masked]> writes:
> On Wed, Jan 09, 2002 at 02:33:32AM +0300, Alexander Kotelnikov wrote:

I put fvwm-workers on the cc list.  You don't want just my opinion
on this.

> > Don't you think that this grab is a consequence of the fact that
> > outline move/resize is used to increase fvwm performace and if fvwm
> > wont grab server while these moves/resizes we will lose its main
> > feature?
> 

> Also, performance is not the only reason to use outline mode.
> Outlines are easier to position accurately, and outline resize does
> not make clients redraw themselves repeatedly while the resize is
> happening; in some cases (netscape comes to mind) the repeated redraw
> can cause a badly written application to crash, lose data, etc.

If I remember, one of the complaints about the server grab is
that xmms stopped playing.  You might consider filing a bug report
with the xmms folks.  I don't see why they would have music playing
in the same thread that is updating the display.  Maybe they don't
use threads, but it might help if they did.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 9 Jan 2002 17:40:31 +0100

> those pixels against the outline?

No.

> > You might consider filing a bug report with the xmms folks.

This is *definitely* an xmms bug.  It is perfectly legal for any
application to grab the X server at any time, although it should
be released as fast as possible.  Running tasks that work in real
time in the same process/thread as X11 calls is simply stupid.  If
we'd fix that in fvwm there are thousands of other programs that
can potentially cause similar problems.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20

---

From: "Paul Smith"<[email-masked]>
Date: 09 Jan 2002 12:29:32 -0500

>> > You might consider filing a bug report with the xmms folks.

  dv> This is *definitely* an xmms bug.  It is perfectly legal for any
  dv> application to grab the X server at any time, although it should
  dv> be released as fast as possible.  Running tasks that work in real
  dv> time in the same process/thread as X11 calls is simply stupid.  If
  dv> we'd fix that in fvwm there are thousands of other programs that
  dv> can potentially cause similar problems.

Isn't this what happens when you post a menu, for example?  The server
is grabbed?  That's why you can whiz the mouse around the screen and the
menu stays posted and other windows don't get focus (even if you have
focus follows mouse) and the mouse cursor doesn't change shape, etc.

And I don't men just FVWM menus, I mean menus in just about any app.

Or, is that something different?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]> HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Wed, 09 Jan 2002 13:17:57 -0500

> Or, is that something different?

Thats something different, those menus grab the pointer, not
the server.

FrFrom [email-masked]  Fri Jan 11 08:20:50 2002
To: [email-masked]
Subject: Re: FvwmButtons do not respect Pixmap sometimes
From: Alexander Kotelnikov <[email-masked]>
Organization: pale
Date: Fri, 11 Jan 2002 17:20:03 +0300
Lines: 48
Sender: [email-masked]

>>>>> On Fri, 11 Jan 2002 13:34:23 +0100
>>>>> "Dominik" == Dominik Vogt <[email-masked]> wrote:
Dominik> 
Dominik> On Fri, Jan 11, 2002 at 02:41:37PM +0300, Alexander Kotelnikov wrote:
>> >>>>> On Fri, 11 Jan 2002 11:57:41 +0100
>> >>>>> "Dominik" == Dominik Vogt <[email-masked]> wrote:
Dominik> 
Dominik> On Fri, Jan 11, 2002 at 04:03:40AM +0300, Alexander Kotelnikov wrote:
>> >> If button is something like
>> >> *FvwmButtons(Title "Title", Action 'Exec something&')
>> >> and we have 
>> >> *FvwmButtonsPixmap pixmap.xpm
>> >> Button title will not be coverd with pixmap.xpm
>> >> 
>> >> I think this is not desired bahaviour.
Dominik> 
Dominik> I agree that it's not the desired effect in all cases, but it is
Dominik> definitely the way the code was designed (i.e. on purpose, not by
Dominik> accident).  I think it's easy to add an option that controls this.
Dominik> 
>> In other words, this will not be fixed?
Dominik> 
Dominik> If you mean to implement it in the way you describe and scrap the
Dominik> old code, then - yes - it won't be fixed.  That does not mean that
Dominik> I won't implement another option for pixmaps on the button that
Dominik> allows to choose one of both alternatives.

Then I thin a comment should be paleced in FvwmButtons man page near
       *FvwmButtons: Pixmap pixmapfile
              Specifies  a  background  pixmap  to  use.  Specify
              "none" for a transparent background.

Dominik> 
>> Can you tell me what is this purpose?
Dominik> 
Dominik> I think the idea was to have a labeled button with a pixmap above
Dominik> it that indicates the action that the button triggers.  You are

Hmm.. This is done with "Icon", not with all buttons wide "Pixmap", or
I understand something incorrectly?

Dominik> probably thinking of the pixmap as a background for the text.
Dominik> Both approaches are certainly valid, but only the first one is
Dominik> implemented at this time.

-- 
Alexander Kotelnikov
Saint-Petersburg, Russia

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Sun, 13 Jan 2002 13:50:44 +0600

> can potentially cause similar problems.

	Just for a record: RealPlayer for Linux also has this bug.  I've
looked through the Preferences dialog, and it doesn't seem to have a
"play in separate thread" flag, while the program runs as several
processes.  Probably just a bad coding.  The version is 8.0.3.421,
linux-2.0-libc6-i386-gcc2.95.  I don't think that filing a bug report to
Real would help anything.

	_________________________________________
	  Dmitry Yu. Bolkhovityanov
	  The Budker Institute of Nuclear Physics
	  Novosibirsk, Russia

---

From: Dan Espen <[email-masked]>
Date: Mon, 14 Jan 2002 09:25:16 -0500

> Real would help anything.

Hmm, I forget who the original poster here is.

Anyway, "tcd" seems to keep playing while wire-frame resizes
are being used, even through the xterm stops updating.

I don't see why Real wouldn't want to fix their product.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 14 Jan 2002 17:11:28 +0100

> I don't see why Real wouldn't want to fix their product.

Triggered by that discussion I tried how various systems react
when a new window is mapped while a window is being moved:

  Kwm

   - wire frame: window is mapped after move completes
   - opaque:     window is mapped immediately

  A popular operating system by M$

   - opaque:     move operation is terminated immediately and the
                 new window is mapped
   - wire frame: didn't try

  Mac OS 9

   - wire frame: freezes whole system until motion ends
   - opaque:     didn't try

  Fvwm
  
   - opaque:     window is mapped after move completes
   - wire frame: window is mapped after move completes

I think fvwm's behaviour is not optimal.  Fvwm could handle a lot
of events even during opaque window motion.  The only problem I
can see is that a newly mapped window might have to be placed
manually.

Bye

Dominik ^_^  ^_^