#111 closed defect (fixed)

Loading palette causes a graphical glitch

Reported by: D Gowers Owned by: Thomas Bernard
Priority: major Milestone:
Component: GrafX2 Version: 2.7
Keywords: Cc:

Description

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)

Attachments (3)

45-29::892x555+0,0 001.png (20.1 KB) - added by D Gowers 15 months ago.
screenshot
16x16_tiles.png (1.0 KB) - added by D Gowers 15 months ago.
palette source
47-54.png (36.0 KB) - added by D Gowers 14 months ago.
Statistics screenshot

Download all attachments as: .zip

Change History (18)

Changed 15 months ago by D Gowers

Attachment: 45-29::892x555+0,0 001.png added

screenshot

Changed 15 months ago by D Gowers

Attachment: 16x16_tiles.png added

palette source

comment:1 Changed 14 months ago by Thomas Bernard

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

comment:2 Changed 14 months ago by PulkoMandy

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

comment:3 Changed 14 months ago by 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 ?

comment:4 Changed 14 months ago by D Gowers

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

comment:5 Changed 14 months ago by 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.)

Changed 14 months ago by D Gowers

Attachment: 47-54.png added

Statistics screenshot

comment:6 Changed 14 months ago by 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

comment:7 Changed 14 months ago by Thomas Bernard

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

comment:8 Changed 14 months ago by 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.

comment:9 Changed 14 months ago by Thomas Bernard

yep probably inside Remap_screen_after_menu_colors_change()

comment:10 Changed 14 months ago by 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.

Last edited 14 months ago by D Gowers (previous) (diff)

comment:11 Changed 14 months ago by 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.

comment:12 Changed 14 months ago by 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]];
         }

comment:13 Changed 14 months ago by 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

comment:14 Changed 14 months ago by Thomas Bernard

Owner: changed from pulkomandy to Thomas Bernard
Status: newaccepted

comment:15 Changed 14 months ago by Thomas Bernard

Resolution: fixed
Status: acceptedclosed
Note: See TracTickets for help on using tickets.