Opened 4 years ago
Closed 4 years ago
#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)
Change History (18)
by , 4 years ago
Attachment: | 45-29::892x555+0,0 001.png added |
---|
comment:2 by , 4 years ago
It looks like about half the screen. Could be a problem involving x2 pixels mode, and SDL2 256-color mode emulation?
comment:3 by , 4 years ago
Can you tell what is your "Pixel size" setting in the "Picture & screen sizes" dialog,
and the "Menu ratio adapt" from the Settings ?
comment:5 by , 4 years ago
I'm still not reproducing.
@D Gowers
could you attach a screen capture of the "statistics" dialog
(the one with all the versions etc.)
comment:6 by , 4 years ago
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 by , 4 years ago
@D gowers
Do you reproduce when building against SDL2 or x11 ?
$ API=sdl2 make
$ API=x11 make
comment:8 by , 4 years ago
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:10 by , 4 years ago
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.
comment:11 by , 4 years ago
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 by , 4 years ago
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 by , 4 years ago
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 by , 4 years ago
Owner: | changed from | to
---|---|
Status: | new → accepted |
comment:15 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
screenshot