Loading palette causes a graphical glitch

[D Gowers]

Palette dialog is half rendered in one palette and half in another (screenshot attached).
OKing the dialog and reopening renders the dialog normally.

Steps to reproduce:

• start grafx2-sdl
• leftclick 'Pal'
• Click 'Load
• Set the filetype selector to png
• load the provided file (32 color palette, plus some grays near #255 for grafx2's use)

Dialog is then split in two across a vertical line which passes through the Cancel button. The dialog remains fully operable. Clicking on any element does not cause it to rerender in the 'new' colors (or in the old colors either! Any elements that are visually 'split' remain split.); the colors any part of any element is rendered in appears to be entirely dependent on its location within the dialog.

Slightly different actions appear to cause a different set of 'old colors': for example, first accidentally causing a load error by clicking on an empty file, then loading the correct file, caused the 'old colors' to be almost entirely blacked out.

Since this is a temporary cosmetic glitch, I'm reporting mainly because of how strange it is.

OS: Arch Linux x86_64 (Linux 5.0.5)

[D Gowers]

screenshot

[D Gowers]

palette source

[Thomas Bernard]

I do not reproduce with version 2.7wip2650
(FreeBSD / sdl)

[PulkoMandy]

It looks like about half the screen. Could be a problem involving x2 pixels mode, and SDL2 256-color mode emulation?

[Thomas Bernard]

Can you tell what is your "Pixel size" setting in the "Picture & screen sizes" dialog,
and the "Menu ratio adapt" from the Settings ?

[D Gowers]

Pixel size is indeed 2x2.
Menu ratio adapt is also x2.

[Thomas Bernard]

I'm still not reproducing.
@D Gowers
could you attach a screen capture of the "statistics" dialog
(the one with all the versions etc.)

[D Gowers]

Statistics screenshot

[Thomas Bernard]

So you're using SDL1.2.15
The 8bit => true color conversion is made by SDL 1. (SDL 2.x only supports true color modes)

it can be a bug in SDL, or also in Remap_screen_after_menu_colors_change()
because when the palette is changed, we must change the 4 colors used for the menu

[Thomas Bernard]

@D gowers
Do you reproduce when building against SDL2 or x11 ?
$ API=sdl2 make
$ API=x11 make

[D Gowers]

API=sdl2: Identical glitch is present (also wow, the guidelines drawn for rectangle / ellipse tools totally destroy the performance in this version.. 3-6 fps, at a guess)

API=x11: Identical glitch is present.

I guess that means the bug *is* inside Grafx2.

[Thomas Bernard]

yep probably inside Remap_screen_after_menu_colors_change()

[D Gowers]

I just thought to try different pixel sizes.

The result can be easily summarized:

• The glitch is present in all API= versions, and the split (if it occurs; see below) is reliably placed on the same 'virtual pixel column' (pixel column as considered before applying the pixel scaling to it) regardless of the API= version
• There are some very minor visual differences (edges were being redrawn in a different color in X11, IIRC)
• The horizontal part of the pixel size multiplier appears to be the only thing that matters. When it is set to 1, the glitch does not occur. When it is set to 2, the split is as shown in the screenshot. When it is set to 3, the split is to the left of that. When it is set to 4, the split is even further to the left.
• Thus the glitch does not occur with 1x1 or 1x2 pixel sizes, and does occur for all other sizes.

Perhaps I should also mention, the window is maximized (Window size reported as 1438 x 879). Probably only the horizontal size is relevant to this bug.

[yrizoud@…]

I was able to reproduce it.
Pixel ratio > 1x1 is necessary
In fact the issue happens as soon you select the file in the Load (palette) screen : Grafx2 draws a preview of the palette, while changing the window colors at the same time, and if you move the window a little you can see that the window under it (the Palette window) is already damaged.
This is probably a unique situation where the "Load" dialog is displayed with an other window under it : "Load brush" window isn't in this situtation because it closes the Brush window first.

[yrizoud@…]

The following fixes the issue in Remap_UI_in_window_backgrounds() :

         min_x -= Window_stack[i].Pos_X;
         max_x -= Window_stack[i].Pos_X;
         // do the conversion
-        for (x = min_x; x < max_x; x++)
+        for (x = min_x*Pixel_width; x < max_x*Pixel_width; x++)
         {
           p[x] = conversion_table[p[x]];
         }

[Thomas Bernard]

Thank you. I've finally been able to reproduce

and than you for the fix :
​https://gitlab.com/GrafX2/grafX2/merge_requests/196

[Thomas Bernard]

​https://gitlab.com/GrafX2/grafX2/commit/91e028794a48588ba26cc69ab5d57d8ef843a3e6