Subject: CVS olicha: * Clip text and icon drawing for the fvwm icons

From: FVWM CVS <[email-masked]>
Date: Mon, 23 Sep 2002 02:40:13 -0500

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	olicha	02/09/23 02:40:13

Modified files:
	.              : ChangeLog 
	fvwm           : add_window.c borders.c events.c geometry.c 
	                 icons.c icons.h update.c 
	libs           : FRender.c Rectangles.c Rectangles.h 
	modules        : ChangeLog 
	modules/FvwmButtons: FvwmButtons.c draw.c draw.h dynamic.c 

Log message:
* Clip text and icon drawing for the fvwm icons
* Fixed(?) XRender rendering with some Xserver
* Some preparation for clipping in FvwmButtons

--
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: Mikhael Goikhman <[email-masked]>
Date: Mon, 23 Sep 2002 09:19:30 +0000

> * Clip text and icon drawing for the fvwm icons

Icons are practically do not flicker now when should be partially redrawn.
But png icons still flicker *a lot* by merelly focusing/unfocussing them.

I think some bug with icon title drawing was introduced.
To reproduce it, I restart with no config, then define some

  Style ** Icon norm/unknown.xpm
  OpaqueMoveSize unlimited  # not really needed to reproduce problems

Then iconify several windows from FvwmConsole and select one or another.

If you defined xpm icon do:

  Style * IconBox 0 0 1000 1000, IconFill l t

With xpm icon, title bg is incorrect until you focus/unfocus an icon.
With png icon, title text randomly disappears/appears when you focus it.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 24 Sep 2002 12:22:26 +0200

> But png icons still flicker *a lot* by merelly focusing/unfocussing them.

Is it ok now?
 
> With png icon, title text randomly disappears/appears when you focus it.

Is it fixed now?

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 25 Sep 2002 13:49:19 +0000

> > But png icons still flicker *a lot* by merelly focusing/unfocussing them.

It seems that enter/leave now does not flicker (or flickers less).
But focusing/unfocussing does flicker, you may open several png icons.

> > With png icon, title text randomly disappears/appears when you focus it.

The text does not disappear now, but I may see some rectangles in title
text are painted in the wrong bg until an icon is focussed. For example,
I may Restart with an icon on another page, then go to that page and see
incorrect bg (sh and hi are ok). Tell me if you can't reproduce this.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 25 Sep 2002 19:35:10 +0200

> But focusing/unfocussing does flicker, you may open several png icons.

Yes, I cannot do a lot here (without horible tests). The icon pixmap
is redraw when at focusing/unfocussing as drawing depends on the
HilightColors/Colors.
So here the icon does not flicker it is redrawn o:)
Try, Colorset 1 IconAlpha 40 (ft).

> incorrect bg (sh and hi are ok). Tell me if you can't reproduce this.

Ooops, fixed soon.

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 25 Sep 2002 19:45:04 +0000

> Try, Colorset 1 IconAlpha 40 (ft).

I didn't know this line affects both Icons and pager's mini icons, nice.

We really need a separate optional IconColorset (HilightIconColorset?),
since so many users asked for it, I think you prepared everything for it.

Returning to our flickering. It is annoying. Can the drawing be done
somehow behind the scene, so that the final image (that is the same image)
would not cause flickering?

Ok, one more bug for you. Open xterm and FvwmConsole, define png icons.
In FvwmConsole do "All (XTerm) Iconify on", the xterm icon is visible,
the FvwmConsole icon is empty, but title is ok.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 26 Sep 2002 10:17:07 +0200

> I didn't know this line affects both Icons and pager's mini icons, nice.

As icons and Pager mini-windows use Colorset 1 in fvwm-themes.
 
> since so many users asked for it, I think you prepared everything for it.

I think we need a lot of new icon styles:

IconTitleColorset
HilightIconTitleColorset
IconBackgroundStyle [Colorset cset] [Frame x] [Padding x y]

and maybe a HilightIconBackgroundStyle.

> would not cause flickering?

I do not think this is possible. With an icon pix with an alpha
channel, we must set the icon bg to the ParentalRelative pixmap. Then
when we draw we should first clear the icon bg, with the icon at the
good screen position so that the icon bg is "root" transparent. Then
we can draw the icon and the alpha channel is well composed with the
root bg.  The flickering you can see is caused by the icon bg
clearing.

The only way I see to remove this flickering at focus change, is to
compare certain entries of the hi_cs and cs colorsets and to draw only
if these entries are different *or* the icons has not been already
drawn. This leads to add a new entries in the FvwmWindow struct: "an
icon draw count". This is a bit complex for this flickering which is
caused by an icon state change (so this is maybe a feature o:) ????
 
> the FvwmConsole icon is empty, but title is ok.

Yes, a big miss print in the code. This will be fixed this day.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 26 Sep 2002 12:14:02 +0200

> caused by an icon state change (so this is maybe a feature o:) ????

Ok, I have fixed this flickering. In fact I think that the icon draw
count is not needed, we always have the appropriate Expose event.
Can you make some tests?

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 26 Sep 2002 12:16:40 +0000

> > and maybe a HilightIconBackgroundStyle.

Maybe. It seems to be needed. But then maybe incorporate IconSize into
this as well? Something like:

  Style * IconStyle \
    TitleColorset cs,         \  # defaults to Colorset
    HilightTitleColorset cs,  \  # defaults to HilightColorset
    FrameColorset cs,         \  # defaults to Colorset
    HilightFrameColorset cs,  \  # defaults to FrameColorset/HilightColorset
    [!]Transparent,           \  # defaults to True, for *FrameColorset
    Padding x y,              \  # defaults to 0 0
    Relief n,                 \  # defaults to 0
    Size [x y [x2 y2]],       \  # defaults to -1 -1 -1 -1, now IconSize

But this is only a way to group options. I think you suggest to divide
this differently if hilight icons may have another size, something like:

  Style * IconStyle \
    TitleColorset cs,         \  # defaults to Colorset
    FrameColorset cs,         \  # defaults to Colorset
    [!]Transparent,           \  # defaults to True, for FrameColorset
    Padding x y,              \  # defaults to 0 0
    Relief n,                 \  # defaults to 0
    Size [x y [x2 y2]],       \  # defaults to -1 -1 -1 -1, now IconSize

  Style * HilightIconStyle \
    TitleColorset cs,         \  # defaults to HilightColorset
    FrameColorset cs,         \  # defaults to IconStyle/HilightColorset
    [!]Transparent,           \  # defaults to IconStyle/True
    Padding x y,              \  # defaults to IconStyle/0 0
    Relief n,                 \  # defaults to IconStyle/0
    Size [x y [x2 y2]],       \  # defaults to IconStyle/-1 -1 -1 -1

Of course, it is possible to think about other functional divisions.
Any of these are ok for me, but the second allows more fun effects.
But adding effects that will flicker anyway is not that good. :)

> > > somehow behind the scene, so that the final image (that is the same
> > > image) would not cause flickering?
> > 

It works nicely except that now IconAlpha and IconTint without arguments
do not take effect immediatelly. Only after iconifying/deiconifying.

Still I think it is possible to draw the root bg and then the image in one
step, i.e. without flickering that is still happens if cs != cs_hi.
But this is only my guess, I am not an X expert at all.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 26 Sep 2002 16:08:34 +0200

>     Size [x y [x2 y2]],       \  # defaults to IconStyle/-1 -1 -1 -1

Oh, no no no!  Please no nested style definitions.  That's
unparseable and unreadable.  The "Decor" stuff already proves that
it is the wrong way.

[snip]

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Olivier Chapuis <[email-masked]>
Date: Thu, 26 Sep 2002 16:41:49 +0200

> do not take effect immediatelly. Only after iconifying/deiconifying.

Yep, under certain circonstance. Fixed soon.
 
> But this is only my guess, I am not an X expert at all.

Maybe this is possible, but I am sceptical. I've recently make a lot
of experimentation with "transparency" and I saw only 3 methods to
create transparency. Maybe one day XRender will be able to really give
to us Transparency.

How to get a window with a transparent background?

1 - Create a window with the ParentRelative pixmap as bg. Map it, you
have the root bg on the _visible_ part of the window (that's all, try
to XCopyArea the window on a pixmap. Moreover you need a window
manager that allows you to set the "frames" bg with the ParentRelative
pixmap).

2 - If your server have backing store. Create a window with
ParentRelative bg with backing store "Always". Do not map it
(optional) but XMoveResize at the wanted position. Clear the window.
You have it!!!!!!!
This way you can make a screen shot of any part of the root win bg,
you can even safely copy the window into a pixmap (backing
store). This idea is used to set the _bg_ of a window with a tinted
version of the root window bg (Transparent + Tint colorset options,
this "works" only with menus, Ident and IconMan at the present time).

3 - You have the pixmap with which the root win bg has been set with
(e.g., you use fvwm-root or Esetroot or FvwmBacker with RetainPixmap).
Then just use translations and XCopyArea.

So the only general method I know is 1. It causes flickering when you
want to update an icon with some alpha as you need to clear the bg to
reset the bg to the root win bg (so that the alpha composition is
good). You cannot do this out of screen.

What we can do is to see if method 3 is available and use it if it
is. But really, it will be some work for almost nothing ...

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 26 Sep 2002 18:04:47 +0000

On 26 Sep 2002 16:08:34 +0200, Dominik Vogt wrote:
> unparseable and unreadable.

Well, I only tried to discuss the needs (structures to be used) first, not
the syntax. The syntax may be just "Icon" and "HilightIcon" prefix to all
the fields if we decide we don't need external (not inline) structures.

But even if we only need flat Style options, I am not so sure the flat
syntax is the best thing. Style command is already polluted. Grouping
would not hurt. For me the following:

  Style * IconStyle TitleColorset 8
  Style * FocusPolicy FocusClickModifiers CS

is not less readable or parsable than:

  Style * IconTitleColorset 8
  Style * FPFocusClickModifiers CS

But the first has some advantages like to actually _reduce_ the syntax,
since usually all options inside one group are defined in one place, so
they may be grouped. Additionally, operations like copying the FocusPolicy
style group from "XTerm" to "gnome-terminal" would be possible, not only
CopyStyle. The man Style entry would be more structured.

I think Tim suggested in the past some solution to split Style.
Is this solution still relevant, Tim?

> The "Decor" stuff already proves that it is the wrong way.

I don't say that flat Style options is a bad thing, it is good for
performance, but syntax should not be flat. Decors are fully irrelevant.

But my thoughts are, when we move TitleStyle/ButtonStyle/BorderStyle
commands to Style, we will need these Style groups, yes.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 27 Sep 2002 09:35:26 +0200

[snip]
> commands to Style, we will need these Style groups, yes.

I think the grouping is on the wrong level.  It does not matter if
the styles names are

  IconStyleTitleColorset

  (could be augmented with an "IconStyle" command that is the same
  as Style but prefixes all style names with "IconStyle" first).

or

  IconStyle TitleColorset

  (although it is much more difficult to parse)

The biggest flaw is the current style syntax is that there are too
many places that define the same GUI elements.  I proposed that
before:

  Style * IconTitle GuiStyle WindowTitle
  Style * Title WindowTitle
  GuiStyle WindowTitle Title Colorset 8, ReliefWidth 2, ...

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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]