Using a memcpy here is supremely dangerous, because we are writing to
an app_server buffer that we chose the length for, but using a size
that came from the client. And, indeed, because the buffer can contain
padding if the BBitmap was allocated with a non-standard BytesPerRow,
we will overflow the buffer and corrupt memory, causing app_server to crash.
So, instead, reorganize parameters a bit, and pass BytesPerRow along
with the other data needed to instantiate the bitmap, and then use
ImportBits.
Fixes an app_server crash I triggered with the experimental libX11
compatibility layer.
This way, we get the user's environment variables, and so should
input_server, which is started by app_server.
This should, after 6 years, fix #12534. We may need to revisit this
when/if we add multiuser support, but that is a problem for another day.
Change-Id: I04698306bc68a585acd232e9f9d29c50bc170a1f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4506
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We still do not know if the accelerant buffers are graphics memory or not,
but in my testing (on the VESA driver), the only time I could get _CopyRect
to be called was where the buffer was in fact not graphics memory.
So that should provide a performance improvement there.
On the other end of things, this should resolve unaligned video memory
access problems on RISCV, and potentially other platforms, as gfxcpy32
did not attempt to align pointers; it should also improve performance
as memcpy will usually be faster than our custom gfxcpy here.
Most of this code has not been touched since 2006 or so.
Change-Id: I40b0345c5d47f2b45acafb14f03fd3a24d2042a8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4315
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It just causes confusion and is wrong in the case where double buffering
status changed during the object lifetime.
Change-Id: Ia1a9ae3f5a1b1b7d521b79c7d1c7be92cef60a06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4633
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This should resolve the problems where the framebuffer driver was
getting picked instead of the "real" graphics driver, when available,
which led to the framebuffer driver getting merged back into the VESA
driver.
Change-Id: I4ad00d2ac3b5dda34aa63f8691d4cbb85e4f6bb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4616
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
For inverse masks the real bounds rect is the canvas, as the points that
pass through are the ones not drawn.
Change-Id: I420a5eca419b215b55e4c2362e2c7646465a4cd3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4455
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Only on non-GCC2 for now, as GCC2 does not have -fvisibility.
An opt-out is left as a possibility, and is unfortunately necessary
for libshared and libicon, as these two are used even in WebKit instead
of linking to the .a. However, libcolumnlistview, libagg, and a whole
bunch of others are now no longer exported, so this is already a major
improvement on what symbols we were leaking.
This may provide performance differences for consumers of these APIs,
as GCC and the linker are now free to merge and directly use functions
that previously could have been semantically interposed. AGG usage in
app_server, especially, may benefit.
We can also now remove the addition from libnetservices, so do that.
It's not allowed to enable the screen before having set a mode. At least
in the case of the intel_extreme driver, this creates some problem. Move
the call just a bit later in the init process, where the mode is already
set.
Change-Id: Iaa665f0edc15316890032f1a5928f33634dc8749
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4362
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: François Revol <revol@free.fr>
Reviewed-by: <BeagleJoe13@gmail.com>
There was some confusion (and a TODO indicating it) in ServerFont.cpp,
because the notion of "font face" from the Be API is partially
implemented using different font manager styles (bold, italic, etc),
and partially by keeping flags in a separate variable for drawing
extra things or modifying the drawing (underscore, strikeout, ...).
The implementation did not actually preserve the extra flags, and so the
underscore face attribute was lost.
Implement the actual underlining of the text in AGGTextRenderer. This
implementation is a naive one so far. In particular there are the
following limitations:
1. Line is drawn over the text - no nice gaps for descents. Ideally, the
line should not touch the letter descents, and leave some space
around them. I don't know how to retrieve the contour - it appears to
me this might require bigger refactoring of this code. I have left in
my experiments commented out in the code.
2. If the text run ends with whitespace, the whitespace is not underlined
as it should. In particular if another text run is drawn next to it
and it's expected that the underline is continuous between the two.
Change-Id: I8d78b8e1eceddff0a7d98e5a49659e7b03fd89a0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3041
Reviewed-by: Kacper Kasper <kacperkasper@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Integer overflow caused bitmap buffer creation of wrong size and out of
bounds access when large bitmap was created. Now allocation failure is
reported for large bitmaps.
This prevents app_server from crashing while playing YouTube in WebPositive.
Fixes #16489.
Change-Id: I297aa6e3b79b32a486d297f1239a1fd4397a8a36
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4209
Reviewed-by: Sergei Reznikov <diver@gelios.net>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Use glyph 0 when no glyph is found for a character in the current font
nor any of the fallbacks.
HasGlyphs has to bypass LayoutGlyphs because we want it to mark this
case as false, while still checking the fallbacks.
Change-Id: Ief8d9d53c91992c659922fb56b79be7172f4ab0d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4144
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Screen may be turned off if video card is not supported by firmware and boot
loader.
Change-Id: Ie60fc00da281ec3781084dd97466a68b885fde7b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4114
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
FreeType only provides some font parameters for scalable fonts. In
particular, we use the FT_Face values of units_per_EM, ascender,
descender and height, which are 0 for bitmap-only fonts.
Part of #16938.
Change-Id: Iea2d87ad95f3bc1c2e27fb041da0a27c6e68be91
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4042
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- Allows applications to be resized without the window contents resizing with the window frame.
- Due to the nature of out-of-tree decorators using private APIs, this will require all pre-existing decorators to be rebuilt
- Newer decorators won't work on older versions of Haiku...
- Also has some formatting with license headers.
- Fixes #2724
Change-Id: Id0b45e7bbc0b636e6dffbd396eb584bf348b5296
Reviewed-on: https://review.haiku-os.org/c/haiku/+/344
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Jacob Secunda <secundaja@gmail.com>
Also use the correct symbol for the return key (we were using another
similar arrow because this one was not available in DejaVu Sans).
Fixes #14034.
Note that build/jam/repositories/HaikuPorts ships an old version of the
Noto package that does not include the Symbols2 font. It should be
updated. Adding this to the pile of lagging behind packages, alongside
icu, mawk/gawk, and tnftp. Can anyone take care of it?
Make object ownership explicit by use of ObjectDeleter where possible.
Change-Id: I499a00aa3390d1510ae284419e73faffa5166430
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2695
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Some code in a just merged patch needs another one that's still being
discussed on Gerrit. Extract just the parts we need to get things
building again.
Make the glyph layout engine look for a suitable font fallback for each
missing character, instead of using the first one found for all of them.
Solves #16404, #16213, maybe other garbled text issues.
Does not solve similar issues of getting slightly different positions and
widths for a whole string than for the sum of its parts due to subpixel
rendering (cf #15007 comment 2).
Change-Id: I40664e32c8ecd5f09e10aa7a60fcdaec230471b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3273
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The brightness is saved in the screen configurations of the first
workspace. For now, all screens get the same brightness (I can't get
screen IDs to work today). Since we only support setting the brightness
for laptop displays for now, this shouldn't matter. It can be fixed when
app_server gets actual multiple display support.
Fixes #14254
Change-Id: Ib33aa65a73407a65bd469d0efa8542210fec02d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/362
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Split apart the work done in https://review.haiku-os.org/c/haiku/+/2695
in smaller, easier to review parts.
This commit contains self-contained/local changes that are unlikely to
cause problems.
Change-Id: Idae27ca440791423e3d090bcfe33f4cc83bbea3d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3174
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This avoids creaing a semaphore where it is not needed, especially
as most of these locks are never used from another thread (in the
reports in #16246, there are thousands of semaphores from this
with only a small handful having a "last acquirer" != 0.)
sourceRect has phase baked in. If phasecomponents are larger than bitamp bounds
sourceRect no longer intersects and nothing gets drawn.
Change-Id: Ib3f676b8e78e2d941c89e699f9a0ab39cc93e173
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2916
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Augustin Cavalier