With this patch it is possible to create PNG files. Only minimal options
are supported. The PNG is created with one big IDAT chunk containing
only non-compressible DEFLATE blocks.
It's less code, and blit() already handles scaled painters.
Fixes the window server asserting in highdpi mode with a centered
background image. Part of #5017.
draw_scaled_bitmap() has a clearer API (just source and dest rects --
blit_scaled() took those and scale factors and then ignored width and
height on the source rect and it was less clear what it was supposed to
do), and they do mostly the same thing.
The draw_scaled_bitmap() API takes an IntRect as source rect, so it's
currently not always possible to split a big draw_scaled_bitmap() into
two (or more) smaller draw_scaled_bitmap() calls that do the same thing
-- that'd require FloatRects. The compositor kind of wants this to be
possible, but there's already a FIXME about this not looking quite right
with the previous approach either.
draw_scaled_bitmap() handles transparent sources, so after this change
wallpapers with transparency will be blended instead of copied. But that
seems fine, and if not, the Right Fix for that is to remove the alpha
channel from wallpapers after loading them anyways.
As an added bonus, draw_scaled_bitmap() already handles display scale,
so this fixes window server asserts for background images that are shown
as "stretch" (#5017). The window server still asserts for "tile" and
"offset" for now though.
Calling draw_scaled_bitmap() here exposed a bug in it fixed by #5041.
Before that is merged, this change here will cause smearing on the
background image when moving windows around.
Moves Painter away from general affine transport support a bit, but
this scale factor business does feel like it's a bit different.
This is conceptually cleaner (everything should use logical coordinates
as much as possible), and it means the code in GUI::Painter() will work
without changes due to that, but the draw function implementations
overall get a bit murkier (draw_rect() becomes nicer though). Still,
feels like the right direction.
No behavior change.
Bitmap::load_from_file("foo.png", 2) will now look for "foo-2x.png" and
try load that as a bitmap with scale factor 2 if it exists. If it
doesn't, it falls back to the 1x bitmap as normal.
Only places that know that they'll draw the bitmap to a 2x painter
should pass "2" for the second argument.
Use this new API in WindowServer for loading window buttons and
cursors.
As a testing aid, ctrl-shift-super-i can force HighDPI icons off in
HighDPI mode. Toggling between low-res and high-res icons makes it easy
to see if the high-res version of an icon looks right: It should look
like the low-res version, just less jaggy.
We'll likely have to grow a better API for loading scaled resources, but
for now this suffices.
Things to check:
- `chres 640 480` followed by `chres 640 480 2` followed by
`chres 640 480`
- window buttons in window context menu (in task bar and on title bar)
still have low-res icons
- ctrl-shift-super-i in high-res mode toggles sharpness of window
buttons and of arrow cursorf
- arrow cursor hotspot is still where you'd expect
Gfx::Bitmap can now store its scale factor. Normally it's 1, but
in high dpi mode it can be 2.
If a Bitmap with a scale factor of 2 is blitted to a Painter with
scale factor of 2, the pixels can be copied over without any resampling.
(When blitting a Bitmap with a scale factor of 1 to a Painter with scale
factor of 2, the Bitmap is painted at twice its width and height at
paint time. Blitting a Bitmap with a scale factor of 2 to a Painter with
scale factor 1 is not supported.)
A Bitmap with scale factor of 2 reports the same width() and height() as
one with scale factor 1. That's important because many places in the
codebase use a bitmap's width() and height() to layout Widgets, and all
widget coordinates are in logical coordinates as well, per
Documentation/HighDPI.md.
Bitmap grows physical_width() / physical_height() to access the actual
pixel size. Update a few callers that work with pixels to call this
instead.
Make Painter's constructor take its scale factor from the target bitmap
that's passed in, and update its various blit() methods to handle
blitting a 2x bitmap to a 2x painter. This allows removing some gnarly
code in Compositor. (In return, put some new gnarly code in
LibGfxScaleDemo to preserve behavior there.)
No intended behavior change.
decode_png_chunks() is not handling "critical" chunks, unlike
decode_png_size() for example. When we encounter a chunk decoding
failure, e.g. because not enough bytes were left to read, just continue
with decoding the bitmap - which will fail on its own, if we're missing
some required chunk(s).
Fixes#4984.
IPC::File should only be used when there's an actual file to pass.
Invalid ShareableBitmaps don't have a backing file, so fix this by
first encoding a "valid" flag.
Window icons in Taskbar were previously received in WM events with
shbuf ID's. Now that Gfx::ShareableBitmap is backed by anonymous files,
we can easily switch to using those.
Needed for the window server minimize animation.
draw_rect() can't just call draw_line() because that isn't
draw_op()-aware. The draw_op()-awareness in Painter looks a bit ad-hoc,
but that's for another day.
This adds a scale factor to Painter, which will be used for HighDPI
support. It's also a step towards general affine transforms on Painters.
All of Painter's public API takes logical coordinates, while some
internals deal with physical coordinates now. If scale == 1, logical
and physical coordinates are the same. For scale == 2, a 200x100 bitmap
would be covered by a logical {0, 0, 100, 50} rect, while its physical
size would be {0, 0, 200, 100}.
Most of Painter's functions just assert that scale() == 1 is for now,
but most functions called by WindowServer are updated to handle
arbitrary (integer) scale.
Also add a new Demo "LibGfxScaleDemo" that covers the converted
functions and that can be used to iteratively add scaling support
to more functions.
To make Painter's interface deal with logical coordinates only,
make translation() and clip_rect() non-public.
The underlying fill_rect() works correctly, but the special case for
thickness = 1 was not blending the new color with the target pixel's
color, causing RGBA colors to be painted as their RGB counterpart.
