Opened 5 years ago

Closed 5 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)

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

Download all attachments as: .zip

Change History (18)

by D Gowers, 5 years ago

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

screenshot

by D Gowers, 5 years ago

Attachment: 16x16_tiles.png added

palette source

comment:1 by Thomas Bernard, 5 years ago

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

comment:2 by PulkoMandy, 5 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 Thomas Bernard, 5 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:4 by D Gowers, 5 years ago

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

comment:5 by Thomas Bernard, 5 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.)

by D Gowers, 5 years ago

Attachment: 47-54.png added

Statistics screenshot

comment:6 by Thomas Bernard, 5 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 Thomas Bernard, 5 years ago

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

comment:8 by D Gowers, 5 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:9 by Thomas Bernard, 5 years ago

yep probably inside Remap_screen_after_menu_colors_change()

comment:10 by D Gowers, 5 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)
  • 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.

Version 0, edited 5 years ago by D Gowers (next)

comment:11 by yrizoud@…, 5 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 yrizoud@…, 5 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 Thomas Bernard, 5 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 Thomas Bernard, 5 years ago

Owner: changed from pulkomandy to Thomas Bernard
Status: newaccepted

comment:15 by Thomas Bernard, 5 years ago

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