Use a GCC #pragma to always optimize the Painter code with -O3.
This code is performance critical and hotter than anything else in the
system, and this helps quite a bit.
The 2x, 3x and 4x upscaling fast paths benefit greatly from this.
Iterate over the source image instead of the destination image, and blow it
up pixel by pixel. This code will only run for upscaling so we don't need
to worry about anything else.
When both the x and y scale factors are integers, we can avoid a whole bunch
of the pixel lookups in the source image.
This makes 2x scaling a 320x200 bitmap another ~25% faster. :^)
Use templates to specialize draw_scaled_bitmap() so we don't have to blend()
for source without alpha, and also inline the GraphicsBitmap::get_pixel()
logic so we don't have to branch on the bitmap format on every iteration.
This is another ~30% speedup on top of the previous changes. :^)
These bitmaps should only be used as a source bitmap, we won't support
painting into them using Painter. You can however manipulate the raw
pixel data. :^)
I'm eventually gonna want to replace this with something more clever,
like a automagically splicing vector or something, but for now, at least
we move away from immutable Strings.
Finally fixed the weird flaky crashing when resizing Terminal windows.
It was because we were dispatching a signal to "current" from the scheduler.
Yet another thing I dislike about even having a "current" process while
we're in the scheduler. Not sure yet how to fix this.
Let the signal handler's kernel stack be a kmalloc() allocation for now.
Once we can do allocation of consecutive physical pages in the supervisor
memory region, we can use that for all types of kernel stacks.
This patch also adds a Format concept to GraphicsBitmap. For now there are
only two formats: RGB32 and RGBA32. Windows with alpha channel have their
backing stores created in the RGBA32 format.
Use this to make Terminal windows semi-transparent for that comfy rice look.
There is one problem here, in that window compositing overdraw incurs
multiple passes of blending of the same pixels. This leads to a mismatch in
opacity which is obviously not good. I will work on this in a later patch.
The alpha blending is currently straight C++. It should be relatively easy
to optimize this using SSE instructions.
For now I'm just happy with the cute effect. :^)
This is a monster patch that required changing a whole bunch of things.
There are performance and stability issues all over the place, but it works.
Pretty cool, I have to admit :^)
My needs are really quite simple, so I'm just going to add what I need
as I go along. The first thing I needed was a simple box layout with
widgets being able to say whether they prefer fixed or fill for both
their vertical and horizontal sizes.
I also made a simple GStatusBar so FileManager can show how many bytes
worth of files are in the current directory.
Let GButton have an optional icon (GraphicsBitmap) that gets rendered in the
middle of the button if present.
Also add GraphicsBitmap::load_from_file() which allows mmap'ed RGBA32 files.
I wrote a little program to take "raw" files from GIMP and swizzle them into
the correct byte order.
Font now uses the same in-memory format as the font files we have on disk.
This allows us to simply mmap() the font files and not use any additional
memory for them. Very cool! :^)
Hacking on this exposed a bug in file-backed VMObjects where the first client
to instantiate a VMObject for a specific inode also got to decide its size.
Since file-backed VMObjects always have the same size as the underlying file,
this made no sense, so I removed the ability to even set a size in that case.
