David Odin wrote:

But I liked the old behaviour (having the checkerboard fixed to the window) since it really shows that the checkerboard isn't part of the drawable as soon as you pan or scroll the preview, and such, the transparency is more obvious.

Anyway we have to be consistent here. So, I would like to know what you (especially artists) do prefer:

- keep the checkerboard fixed to the drawable for images and previews.

IMO it also makes it more obvious that scrolling and panning really happens - something that mignht be important for the users if thei mage has large parts that are transparent.

> - have the checkerboard fixed to the window for images and previews. >
> Imho, the later is nicer, but Sven told me it could make the scrolling > and panning of the main image window much slower.

That would be an additional problem then.

Michael

Hi,

David Odin writes:

- have the checkerboard fixed to the window for images and previews.

Imho, the later is nicer, but Sven told me it could make the scrolling and panning of the main image window much slower.

It wouldn't affect the plug-in previews since there we redraw the full preview on scrolling anyway (this implementation detail could change though).

In the image window however I expect a very noticeable slowdown for scroll operations. What we are doing in the display code is to use gdk_scroll_window(). This is most easily explained using an example: Say you scroll 10 pixels to the right. What happens is that we copy the content of the window 10 pixels to the left using a screen-to-screen blit. This is usually implemented as an operation that is performed entirely on the graphics card so it uses almost no CPU cycles. Only an area of 10 pixels width actually needs to be redrawn. If we would decouple the checkerboard from the image, we'd have to redraw the whole image display on every scroll operation.

Only if we would let the graphics card do the composition onto the checkerboard, we could consider to link the checkerboard to the window. Modern graphics card are able to do that but GDK lacks an API to use that functionality and there are also certainly people using GIMP on older hardware which doesn't do alpha compositing in hardware.

It would still be interesting to hear about people's preferences. So please ignore my technical comments and tell us what which behaviour you would prefer from a user's point of view.

Sven

Sven Neumann wrote:

It would still be interesting to hear about people's preferences. So please ignore my technical comments and tell us what which behaviour you would prefer from a user's point of view.

I personally like the image preview fixed-checkerboard method, at least on the preview. I don't know how well it would translate onto the main canvas. However ... wouldn't this question be better directed at the user list?

rgds,
Chris

Hi,

Christopher Curtis writes:

I personally like the image preview fixed-checkerboard method, at least on the preview. I don't know how well it would translate onto the main canvas.

I don't think doing it differently in the preview and on the image window is an option at all. Consistency is the most important aspect of an user interface.

Sven

On Wed, Sep 01, 2004 at 11:41:35AM +0200, David Odin wrote:

Anyway we have to be consistent here. So, I would like to know what you (especially artists) do prefer:

- keep the checkerboard fixed to the drawable for images and previews. - have the checkerboard fixed to the window for images and previews.

when i saw this being discussed on the irc, i was thinking about another option. depending on the preview size, the checkerboard can make the transparent image difficult to see (like a text layer where the font is fairly fine and the color is black, for instance) and i instantly imagined that it might be easier to have solid backgrounds for previews. a background color that could be changed on the fly depending on what sort of image you are working on.

even if the previews get "bigger" as seem to be planned, it seems like not having checkerboard in a bigger preview would still be a nice option. even after you can zoom in on previews. and really, it might be the only way to tell the difference between the preview and the image depending on how big and nice they (the previews) continue to become.

perhaps no checkerboard could also be considered?

carol

Hi,

Carol Spears writes:

perhaps no checkerboard could also be considered?

It would have to be optional and I cannot imagine a sane user interface for this. Can you?

Sven

On Thu, Sep 02, 2004 at 03:37:29AM +0200, Sven Neumann wrote:

Hi,

Carol Spears writes:

perhaps no checkerboard could also be considered?

It would have to be optional and I cannot imagine a sane user interface for this. Can you?

scanners? what does this have to do with scanners?

heck, sometimes you cannot see the image on the image even ....

carol

On Wed, Sep 01, 2004 at 06:51:46PM -0700, Carol Spears wrote:

On Thu, Sep 02, 2004 at 03:37:29AM +0200, Sven Neumann wrote:

Hi,

Carol Spears writes:

perhaps no checkerboard could also be considered?

It would have to be optional and I cannot imagine a sane user interface for this. Can you?

scanners? what does this have to do with scanners?

heck, sometimes you cannot see the image on the image even ....

i read this wrong the first time and thought you were talking about something else (not even scanners).

user interface. you can set in preferences that previews dont show the checkerboard for transparency.

this new gimp is so full of interface options -- padding color and window stuff. that is why your comment was confusing to me.

the same way you can change the padding color now. i would not have been able to imagine such an interface to the previews without all those new options for customizing your sessions. all this stuff is sane?

carol

Hi,

Carol Spears writes:

the same way you can change the padding color now. i would not have been able to imagine such an interface to the previews without all those new options for customizing your sessions. all this stuff is sane?

You might not have noticed that we have started to remove options from the user interface. However you should be aware of the fact that we try not to add new options unless there's a very good reason for it.

Actually the plan was to let the plug-in previews respect the settings from gimprc that already exist:

(transparency-size medium-checks)

Sets the size of the checkerboard used to display transparency. Possible values are small-checks, medium-checks and large- checks.

(transparency-type gray-checks)

Sets the manner in which transparency is displayed in images. Possible values are light-checks, gray-checks, dark-checks, white-only, gray-only and black-only.

That would of course mean that the same settings apply to plug-in previews and to image windows.

Sven

Hi,

David Odin writes:

Actually the plan was to let the plug-in previews respect the settings from gimprc that already exist:

(transparency-size medium-checks)

Sets the size of the checkerboard used to display transparency. Possible values are small-checks, medium-checks and large- checks.

(transparency-type gray-checks)

Sets the manner in which transparency is displayed in images. Possible values are light-checks, gray-checks, dark-checks, white-only, gray-only and black-only.

How hard would this be to implement?

It would involve two changes:

(1) Add transparency-size and transparency-type properties to GimpPreviewArea and use them when drawing the checkerboard. (2) Somehow get the preferences to the plug-in.

Step 1 should be pretty much straight-forward. The properties can be copied more or less directly from GimpDisplayConfig (app/config). Checkerboard rendering will become slightly more complex but I don't expect any noticeable slowdown. The code has still some room for optimizations anyway.

There are two possibilities to implement step 2. Either we add a PDB API to access the checkerboard settings:

gimp_gimprc_get_transparency_type() ?? gimp_gimprc_get_transparency_size() ??

or (and I'd prefer that), we pass these settings to the plug-in in the GPConfig message. This is a message that is sent to each plug-in when it is started. We handle this in libgimp and allow the plug-in to access the settings using a simple API. See for example gimp_show_tool_tips() or gimp_display_name().

Using the config message is definitely the prefered way of doing this but unfortunately we are completely braindead and didn't add any padding to the GPConfig struct :( However, there's still hope but things are becoming ugly now. Readers with a weak stomach, please leave now...

The GPConfig struct contains an unused member which is "gamma". This is a double and IIRC a double is guaranteed to be always 8 bytes. So we could remove "gamma" and replace it with two 32bit integers and use those for the transparency settings. We could even squeeze the transparency settings into less than 8 bytes and keep the remaining bytes for future use. Might become useful pretty soon, for example as a way to pass whether color management should be enabled or disabled.

Can anyone think of better ways to do this? Are there any strong objections against the ugly hack I outlined above? Did I overlook something (like for example platforms where a gdouble is not 8 bytes)?

Sven

Hi,

a short followup to myself...

As outlined in my previous mail, the checkerboard settings for the preview should be taken from the gimprc when the preview widget is created. It would be nice though to have a way to change the checkerboard settings for the individual preview widget. I think a right-click menu in the GimpPreviewArea is the way to go here. Somewhat hidden but it would be an expert feature anway. Such a right-click menu would allow users to quickly change to a solid-colored background. As Carol outlined this can be useful if for example you are trying to find the best radius to blur a text layer.

Sven

On Thu, Sep 02, 2004 at 12:36:43PM +0200, Sven Neumann wrote:

You might not have noticed that we have started to remove options from the user interface. However you should be aware of the fact that we try not to add new options unless there's a very good reason for it.

well, no. i did not notice that options have been being removed. i guess i have been so bedazzled by the changes that i have only seen the 2.1 branch improving.

also, i did not use many of those new customizable options (new for gimp-2.0) -- i found them when trying to document it. (i used gimp far too long without padding, for instance)

thank you for considering that there might be different needs for previews and images.

carol

Sven Neumann writes:

or (and I'd prefer that), we pass these settings to the plug-in in the GPConfig message. This is a message that is sent to each plug-in when it is started. We handle this in libgimp and allow the plug-in to access the settings using a simple API. See for example gimp_show_tool_tips() or gimp_display_name().

Using the config message is definitely the prefered way of doing this but unfortunately we are completely braindead and didn't add any padding to the GPConfig struct :( However, there's still hope but things are becoming ugly now. Readers with a weak stomach, please leave now...

The GPConfig struct contains an unused member which is "gamma". This is a double and IIRC a double is guaranteed to be always 8 bytes. So we could remove "gamma" and replace it with two 32bit integers and use those for the transparency settings. We could even squeeze the transparency settings into less than 8 bytes and keep the remaining bytes for future use. Might become useful pretty soon, for example as a way to pass whether color management should be enabled or disabled.

Can anyone think of better ways to do this? Are there any strong objections against the ugly hack I outlined above? Did I overlook something (like for example platforms where a gdouble is not 8 bytes)?

When looking at the struct:

struct _GPConfig {
guint32 version;
guint32 tile_width;
guint32 tile_height;
gint32 shm_ID;
gdouble gamma;
gint8 install_cmap;
gint8 show_tool_tips;
gint32 min_colors;
gint32 gdisp_ID;
gchar *app_name;
gchar *wm_class;
gchar *display_name;
gint32 monitor_number;
};

I see two options:

- using the place "gdouble gamma" uses. - using the two unused bytes after "gint8 show_tool_tips".

I'd suggest we do both and change the struct to:

struct _GPConfig {
guint32 version;
guint32 tile_width;
guint32 tile_height;
gint32 shm_ID;
gint8 gimp_reserved_1;
gint8 gimp_reserved_2;
gint8 gimp_reserved_3;
gint8 gimp_reserved_4;
gint8 gimp_reserved_5;
gint8 gimp_reserved_6;
gint8 gimp_reserved_7;
gint8 gimp_reserved_8;
gint8 install_cmap;
gint8 show_tool_tips;
gint8 gimp_reserved_9;
gint8 gimp_reserved_10;
gint32 min_colors;
gint32 gdisp_ID;
gchar *app_name;
gchar *wm_class;
gchar *display_name;
gint32 monitor_number;
};

Which should be binary compatible on all platforms.

ciao, --mitch

On Thu, Sep 02, 2004 at 08:08:23PM +0200, Michael Natterer wrote:

struct _GPConfig
{
guint32 version;
guint32 tile_width;
guint32 tile_height;
gint32 shm_ID;
gdouble gamma;
gint8 install_cmap;
gint8 show_tool_tips;
gint32 min_colors;
gint32 gdisp_ID;
gchar *app_name;
gchar *wm_class;
gchar *display_name;
gint32 monitor_number;
};

I see two options:

- using the place "gdouble gamma" uses. - using the two unused bytes after "gint8 show_tool_tips".

I'd suggest we do both and change the struct to:

struct _GPConfig {
guint32 version;
guint32 tile_width;
guint32 tile_height;
gint32 shm_ID;
gint8 gimp_reserved_1;
gint8 gimp_reserved_2;
gint8 gimp_reserved_3;
gint8 gimp_reserved_4;
gint8 gimp_reserved_5;
gint8 gimp_reserved_6;
gint8 gimp_reserved_7;
gint8 gimp_reserved_8;
gint8 install_cmap;
gint8 show_tool_tips;
gint8 gimp_reserved_9;
gint8 gimp_reserved_10;
gint32 min_colors;
gint32 gdisp_ID;
gchar *app_name;
gchar *wm_class;
gchar *display_name;
gint32 monitor_number;
};

Which should be binary compatible on all platforms.

Sounds good, and gimp_gamma should return 1.0 always (and be marked as deprecated).

-Yosh

Hi,

just FYI: we've by now done the discussed changes to the GPConfig struct. GimpPreviewArea has been changed to make the checkerboard pattern configurable and GimpDrawablePreview already passes the config values to the preview area. What remains to be done is:

(1) Add a popup menu (to GimpPreview) that allows to configure the checkerboard per preview instance.

(2) Add another GimpPreview derived widget to libgimpui. That widget would be used from plug-ins such as the Plasma plug-in which don't need the GimpDrawablePreview functionality. The widget could be called GimpSimplePreview (an idea for a better name would be very much appreciated). It would embed a GimpPreviewArea in a sunken GtkFrame and it would take care of setting a proper size as well as configuring the preview area to the gimprc values.

Sven

On Wed, 2004-09-01 at 11:41 +0200, David Odin wrote:

Imho, the later is nicer, but Sven told me it could make the scrolling and panning of the main image window much slower.

What to you think?

Yeah, I think the fixed checker might be nice - but the speed is more important here, especially with larger images.

//Tuomas

Hi,

here's another preview update for you. A while ago this has been written here:

(1) Add a popup menu (to GimpPreview) that allows to configure the checkerboard per preview instance.

This has been done in the meantime. The menu API might need some changes to allow for these menu items to be merged with other stuff that might be useful for previews.

Other things that have happened with respect to previews:

- previews now respect the selection - previews resize with the plug-in dialog - previews now have a navigation popup window like the one we have in the image window

(2) Add another GimpPreview derived widget to libgimpui. That widget would be used from plug-ins such as the Plasma plug-in which don't need the GimpDrawablePreview functionality. The widget could be called GimpSimplePreview (an idea for a better name would be very much appreciated). It would embed a GimpPreviewArea in a sunken GtkFrame and it would take care of setting a proper size as well as configuring the preview area to the gimprc values.

This hasn't been done yet. Probably because it is still looking for a reasonable name. Everything else would be trivial.

Sven