better call Window::SetMinimized() before calling it from there.
* And since ShowWindow() calls _SendFakeMouseMoved(), we also better don't
call it with the window lock held, or otherwise we would potentially cause
a deadlock.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26760 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Simplified the subpixel related methods for the AGG "pixel format" template
interface, the ones for the solid cover simply pass through the existing
methods, so only one subpixel blending function is left which does the actual
work (this removes a lot of the previously added code)
* Implemented a new rasterizer based on the original AGG rasterizer which
implements subpixel anti-aliasing for any generic AGG vector pipelines. It
is now optionally used in Painter and AGGTextRenderer (for vector fonts, ie
rotated, sheared or big enough fonts) depending on the global subpixel
setting.
* Put all subpixel variables into the new GlobalSubpixelSettings.h|cpp
* Simplified DesktopSettings related classes a bit and renamed previous
FontSubpixelAntialiasing to just SubpixelAntialiasing.
* The private libbe functions for subpixel related settings moved from Font.cpp
to InterfaceDefs.cpp where other such functions live. They are not related
to fonts only anymore.
* Removed the subpixel related settings again from the Fonts preflet and added
them to the Appearance preflet instead.
All of the above implements subpixel anti-aliasing on a global scale, which
to my knowledge no other OS is doing at the moment. Any vector rendering
can optionally use subpixel anti-aliasing in Haiku now. The bitmap cached fonts
are still affected by the Freetype complile time #define to enable the patented
subpixel rasterization (three times wide glyphs). Vector fonts and shapes are
not affected though at the moment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26755 a95241bf-73f2-0310-859d-f6bbb57e9c96
before?! Is about 4% faster than before. If anyone sees a way to make it faster
yet, please shoot! I can watch movies fullscreen on a 2 GHz Core 2 Duo in
VESA with bilinear scaling, but it would be nice to use less CPU... :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26667 a95241bf-73f2-0310-859d-f6bbb57e9c96
const BBitmap* bitmap, BRect bitmapRect, BRect viewRect, uint32 options).
Only option so far is B_FILTER_BITMAP_BILINEAR.
* BView::DrawBitmap[Async](const BBitmap* bitmap, BRect viewRect) was accessing
the bitmap pointer without checking it. Would therefore crash when passing
NULL, unlike the other methods.
* The BPicture code already reserved room for the BBitmap flags, but did not
store the actual flags and neiter use them for anything. Since the bitmap
data is stored anyways, the bitmap creation flags do not matter. So I reused
this for the new bitmap drawing options.
* Rewrote Bitmap.h and removed the B_BITMAP_SCALE_BILINEAR flag again.
* Tried to optimize Painter::_DrawBitmapBilinearCopy32() a little by giving
the compiler better hints. There seems to be a marginal, possibly imagined
speed increase < 0.05 ms. ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26665 a95241bf-73f2-0310-859d-f6bbb57e9c96
need to be interpolated because the x index is right on a source pixel. This
prevents the out of bounds access for the second to last row in the last
column. Also the rightmost pixels where incorrectly interpolated with the
leftmost pixels of the next row. And it actually helps speed too of course.
* Added a compile time option to allocate the filter weighting and index
caches on the heap instead of the cache. I am not sure if it is a problem
though, I recall Haiku threads have quite a lot of stack space. The needed
memory depends on the target size. For a screen with 1920x1200, the caches
would need 12.5 KB. Allocating them on the stack saves about 0.2 ms on my
test system.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26656 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_OP_COPY which is about 2.4 times faster than the AGG version (but of
course less generic). The speed up is even better for smaller and even
scales.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26652 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When drawing BBitmaps with scaling in the app_server, use a bilinear
filter when a bitmap has this flag set. (Hope nobody objects, otherwise
I can revert or improve this. Performance can certainly be improved, since
the AGG implementation is too generic. But that goes for the nearest
neighbor implementation as well.)
* Flags are uint32, fix app_server side code to declare them correctly. Use
appropriate link methods in BBitmap and ServerApp.
* Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32
in B_OP_ALPHA mode).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26649 a95241bf-73f2-0310-859d-f6bbb57e9c96
It works by adjusting the display_mode to have twice the virtual height to
cause the graphics driver to allocate enough frame buffer. Since hardware
acceleration calls are based on geometry locations instead of memory locations,
accelerated calls can work in the offscreen buffer with this method.
Similarily, the new CopyBackToFront() method copies the back buffer into the
front buffer with hardware acceleration. The code is currently disabled, since
not all graphics drivers handle the virtual versus display size correctly,
for example the intel_extreme driver. It works for example with the radeon
driver, but another problem prevents me to judge the benefit of this method.
Most types of screen redraws are flicker free, though, which is the whole point
of the excercise. :-)
Another problem with the current code is the initial mode switch. It does
not try again to double the frame buffer in the fall back code paths. It could
also check the frame buffer memory at all, before even trying to save some
cycles.
To see it in action, uncomment the code at line 508.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26545 a95241bf-73f2-0310-859d-f6bbb57e9c96
hardware accelerated functions could be double buffered.
* Align the rectangle used for arc drawing like those for ellipsis.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26544 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a flag "fIsOffscreenBuffer", which is used to shift the frame buffer
pointer to the position after the visible frame buffer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26543 a95241bf-73f2-0310-859d-f6bbb57e9c96
the front buffer so that derived classes could override it.
* Minor coding style changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26542 a95241bf-73f2-0310-859d-f6bbb57e9c96
Found an incompatibility with BeOS, where Haiku behaves correctly, though,
after our changes: The alpha channel of B_RGB32 bitmaps is ignored, but
B_TRANSPARENT_MAGIC_RGBA32 pixels are considered fully transparent. In BeOS,
B_RGB32 are simply treated as B_RGBA32, but only in B_OP_ALPHA. We have
added a comment as well as the code that would enabled the BeOS behavior.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26436 a95241bf-73f2-0310-859d-f6bbb57e9c96
drawings are used for bitmaps that needed to be converted to B_RGBA32.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26431 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_RGBA32 and B_RGB32 in B_OP_OVER no longer go through the generic AGG code
path, but have an optimized version now, as long as the bitmap is not scaled.
B_RGB32 needs to handle B_TRANSPARENT_MAGIC_RGBA32, while B_RGBA32 works just
like regular alpha blending.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26427 a95241bf-73f2-0310-859d-f6bbb57e9c96
assumed that there was only a single window that was responsible for the
workspaces of a floating/subset window. Of course, any number of windows
can make up the workspaces of those. This fixes bug #2506.
* Added a Window::InSubsetWorkspace() method to complement SubsetWorkspaces().
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26371 a95241bf-73f2-0310-859d-f6bbb57e9c96
problem of subpixel-anti-alised font rendering. Personally I find the method
better than filtering the subpixels, since it is a straighter transition
between unfiltered subpixel aa and grayscale aa. There is no added blur
affecting also innocent neighboring pixels. The filter method is better at
hiding jagged diagonal lines though, so Andrej and I agreed to move this to
a general discussion on the mailing list. Screenshots forthcomming...
* Some additional coding style improvements.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26370 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Extend the app_server protocol by configuration options to turn
subpixel font rendering on/off and also make the glyph hinting optional
(aligning of glyph shapes to the pixel grid).
* Implement the setting in the app_server and also handle the persistency.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26362 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Integrate the subpixel rendering with the existing drawing backend and
the font rendering.
* The font cache has got an additional rendering type for extracting and
caching glyph bitmaps that store subpixel coverage values.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26361 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Extend the existing agg_renderer_region with the two new subpixel methods.
* Remove trailing whitespace.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26360 a95241bf-73f2-0310-859d-f6bbb57e9c96
Sorry, actually this third AGG class is also needed to handle subpixel scanline
coverage.
NOTE: I am trying to break up the large patch into digestable pieces. The
comments come from me not from Andrej, so I am to blame for any confusion! :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26359 a95241bf-73f2-0310-859d-f6bbb57e9c96
Two new AGG classes were needed to handle subpixel scanline coverage values.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26358 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added complementary functions to the set of functions that implement a
drawing_mode, these new functions interpret the coverage values passed
from the AGG rasterizer or another scanline storage as subpixel triplets.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26355 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added marco definitions for subpixel based blending of two 32 bit pixels.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26354 a95241bf-73f2-0310-859d-f6bbb57e9c96
image scan generator matrix was calculated wrongly. The part of the offset
that lies within the bitmap bounds needs to have the scale applied as well.
Maybe this code can be simplified. Appearantly there is not a lot of code
that uses BBitmap drawing this way, perhaps because the R5 version has had
issues with rounding. But MediaPlayer uses this feature for drawing the peak
levels and this is fixed by this change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26324 a95241bf-73f2-0310-859d-f6bbb57e9c96
short cut when no text needs to be rendered. I've seen a crash yesterday in
the app_server test environment when the decorater was drawing something,
although it may also have been because I had a screwed up objects folder
where some objects were not recompiled because I am switching back and forth
between two app_server code folders.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26323 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fixed race conditions when a ServerApp or ServerWindow is created. The
reply to the client that the object has been created successfully was
sent in the thread creating it. Preempted at the wrong time (right after
writing the message to the port) could lead to the object's thread using
the link at the same time, which would screw up all subsequent
communication via that link.
This fixes the problem that mimeset would sometimes fail when building
Haiku in Haiku (can't find the ticket). It probably also fixes#2331,
and the bug that sometimes when a window is opened (Terminal, crash
alert, shutdown window, etc.) it would come up with huge width/height
and tiny other dimension (can't find the ticket).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26192 a95241bf-73f2-0310-859d-f6bbb57e9c96
correct, but it prevents a deadlock that could sometimes be seen right after
booting when the Terminal was supposed to draw the decorator buttons. It
doesn't seem to cause any problems with locking removed (the original drawing
code didn't lock either). Added a TODO to investigate and eventually fix that
though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26170 a95241bf-73f2-0310-859d-f6bbb57e9c96
source bitmaps. The destination is preserved now when encountering such
transparent pixels in the source bitmaps.
* B_OP_ERASE is supposed to replace with the low color whereever a source
bitmap has a non-transparent pixel.
* The B_OP_MIN and B_OP_MAX drawing modes are supposed to select either the
source or destination pixel based on their brightness, not combine the two
pixels' color components into a new pixel. The brightness_for() function is
taken from ColorConversion.cpp in the interface kit. Probably a simpler
algorithm would do as well.
* Handle B_TRANSPARENT_MAGIC_* in all cases when drawing bitmaps with non-alpha
source bitmaps, as all modes except B_OP_COPY are sensitive to transparency.
This should make all drawing modes behave as documented in the BeBook. Except
for B_OP_SELECT, which seems broken under R5, the results compare nicely now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26075 a95241bf-73f2-0310-859d-f6bbb57e9c96
bitmaps in B_OP_INVERT mode does not affect pixels where the source bitmap
was transparent, as noted in the BeBook. Not really sure I'm doing that right
though and probably needs looking into for B_OP_ERASE and B_OP_SELECT too.
Fixes bug #2421 though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26067 a95241bf-73f2-0310-859d-f6bbb57e9c96
an alpha channel of itself, we have to respect B_TRANSPARENT_MAGIC_* pixels
and properly make them transparent. We achive that now by just setting the
alpha to 0 in our converted B_RGBA32 bitmap for each pixel where there is a
B_TRANSPARENT_MAGIC_* pixel in the source. This is not really efficient, but
fixes missing images for example in NetPositive. They were treated as B_RGBA32
while they in fact were B_RGB32 and happened to have all alpha bits set to 0.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25956 a95241bf-73f2-0310-859d-f6bbb57e9c96
the front buffer, draw the bitmap, restore the copy to front buffer state and
unlock. This fixes that the updated button state was not actually copyied to
the front buffer (and therefore visible) when a window was inside an update
(disabling front buffer copying).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25954 a95241bf-73f2-0310-859d-f6bbb57e9c96
need to be drawn each time an update occurs (switching focus/non-focus or
pressed state, involving many graphics card blits and state updates in the
drawing subsystem).
* Provide a shared list of already present bitmaps. All the default decorators
now use the new _GetBitmapForButton static method to get a rendered bitmap
of the button for the given size and state (focus, pressed). If a matching
bitmap exists it is returned, otherwise a new one is created on demand using
a shared BitmapDrawingEngine.
* Cache the colors of the tab and frame for both focus and non-focus states to
avoid always looking them up.
* Added a todo that these bitmaps and the BitmapDrawingEngine are never freed.
They should be freed on app_server quit, but as there are only like 12 of
them anyway I didn't really bother.
* Some cleanup.
This should reduce the waste of cycles for just drawing the default decorator
buttons quite a bit. Probably the whole tab should be pre-rendered though to
also safe the text rendering of the title.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25952 a95241bf-73f2-0310-859d-f6bbb57e9c96
server side UtilityBitmap of a certain size. It sets up the DrawingEngine, the
UtilityBitmap and the BitmapHWInterface necessary so that one can directly
do drawing to a bitmap using the normal DrawingEngine interface. It provides
an ExportToBitmap method that allocates an output UtilityBitmap of a specified
size and color space where the content is put into, so a single instance of a
BitmapDrawingEngine can be reused for various drawing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25951 a95241bf-73f2-0310-859d-f6bbb57e9c96
state of the painter without restoring it afterwards (HighColor and
DrawingMode).
This function is only used in decorators, but as such it could lead to
strange effects. When clicking and holding the close button on the R5
MidiPlayer for example, the background of the scope would suddenly become
the color of the close buttons middle line. As the drawing mode was also
overwritten this could probably have lead to text rendering issues when
zooming applications. As I didn't find a easy way to reproduce such a thing,
this is only theory though.
* Implement the missing IsExclusiveAccessLocked() method in the DrawingEngine
which is not used at the moment. If corresponding debug output is generated
though, it reveals possible locking issues with CopyRegion().
* Remove an empty line in the LineArrayData struct.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25934 a95241bf-73f2-0310-859d-f6bbb57e9c96
session to also include each view's individual update rect (in screen coords).
Should actually not be mush slower than the old version, and hopefully makes
it possible to have smarter BView::Draw() implementations which should make
more than up for any potential speed loss.
* Removed unused version of View::AddTokensForViewsInRegion().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25879 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fix using fScreenAndUserClipping directly in CopyBits() that could crash
when in fScreenAndUserClipping wasn't used (when there's no user clipping
for example).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25856 a95241bf-73f2-0310-859d-f6bbb57e9c96
clipping region pointer.
* Provide _ScreenClipping() that only includes local and screen clipping but
not user clipping.
* Provide ScreenAndUserClipping() that returns screen clipping if no user
clipping is present, or returns a combined region that is then cached.
* Adapt all places where the former methods are used and decide which one to
use depending on the relevance of user clipping.
User clipping is now ignored for background clearing and when determining
whether or not to call Draw() on a view. This should make Haiku behaviourally
compatible with BeOS (confirmed by the ClippingAndRedraw test app) and should
also fix the Firefox redraw issues. Stephan please review!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25854 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added B_BITMAPS_SUPPORT_OVERLAY flag to indicate overlay support for the
color space.
* Rewrote GraphicsDefs.h - the previous one was obvious a copy of the Be header,
including typos and strange white space. I was a bit lazy with respect to
the color space details, and mostly trusted the information provided by the
Be header else.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25793 a95241bf-73f2-0310-859d-f6bbb57e9c96
it can also no longer create a default mode.
* This SetBestMode() function now follows a similar logic than the boot loader,
that is, only the width must not deviate, all other values are chosen as
close to the original as possible.
* VirtualScreen::AddScreen() now follows the same logic as the boot loader in
case no configuration was found, and the current screen has no preferred mode
(for example via EDID). That is, it will first try 1024x768, and then 800x600.
* This means there is no mode change anymore when switching from the boot
loader to the app_server in Qemu and VMware.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25782 a95241bf-73f2-0310-859d-f6bbb57e9c96
* This is not perfect, but it makes Tracker catch up and redraw when the next
event is due. This improves the situation in bug #2212.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25708 a95241bf-73f2-0310-859d-f6bbb57e9c96
Our font has some extra styles and these could be picked up as the
"regular" face by accident, as witnessed by Firefox. Tracked down by
Michael Lotz. Firefox uses the correct font now for it's interface.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25636 a95241bf-73f2-0310-859d-f6bbb57e9c96
to contain headers shared by kernel and userland (mainly libroot).
* Moved quite a few private kernel headers to the new location. Split
several kernel headers into a shared part and one that is still kernel
private. Adjusted all affected Jamfiles and source in the standard x86
build accordingly. The build for other architectures and for test code
may be broken.
* Quite a bit of userland code still includes private kernel headers.
Mostly those are <util/*> headers. The ones that aren't strictly
kernel-only should be moved to some other place (maybe
headers/private/shared/util).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25486 a95241bf-73f2-0310-859d-f6bbb57e9c96
(including any drag bitmap). HWInterface::HideFloatingOverlays() was plain
stupid, I know it did check double buffering at one point, but I must have
removed that when messing with it. But copying anything from back to front
buffer is now not overwriting the cursor area anymore, which is painted
immediatly afterwards. Also moving the cursor invalidates only one rect
if old and new cursor area overlap. All these changes should save some cycles
too. Added TODO with regard to caching the on-the-fly cursor compositing
buffer.
If you have
* a more recent computer
* a decent VESA BIOS which supports your native resolution
* don't need video overlays
... I recommend using the VESA driver.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25479 a95241bf-73f2-0310-859d-f6bbb57e9c96
by BWindow, no longer by the app_server. This should stop the "screen freeze"
effect.
This adds a dependency on libpng.so and libz.so to libbe.so. The same
dependencies and the PNGDump code added here can be removed from the
app_server. I am just waiting for a code review of this before doing that.
This implementation still does not give the client a chance to handle it
differently.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25269 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fixes some strage behavior (moving/disappearing text) in
Appearance preflet while moving a color control chooser.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25035 a95241bf-73f2-0310-859d-f6bbb57e9c96
switching cursors. There was a race condition in case the objects was used
by multiple threads, in which Cursor() could return an already destroyed
object. Note: This doesn't fix a real bug or anything, the change is purely
forward looking in case ServerCursorReference is ever used like that.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24862 a95241bf-73f2-0310-859d-f6bbb57e9c96
a TODO comment that find_directory() won't return the correct directory in
a multi-user environment. This fixes bug #2003.
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24747 a95241bf-73f2-0310-859d-f6bbb57e9c96
current cursor without locking, and did not add a reference while
using the cursor. I have tried to solve both problems by introducing
a simple ServerCursorReference class, which makes sure that the
reference count is properly maintained. There are only two places
where this code was even used, from within ServerApp and when taking
screenshots. Axel, you mentioned in #837 that the code is unsafe, is
this what you meant? This hopefully fixes#837, but it is very hard
to reproduce in the first place, I will close the ticket, but it should
just be reopened if ever encountered again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24741 a95241bf-73f2-0310-859d-f6bbb57e9c96
and their origin and scale influences the current state's origin, since
they can be regarded as within the parent state's coordinate system.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24740 a95241bf-73f2-0310-859d-f6bbb57e9c96
* DrawState::SetOrigin needs to take the view scaling into account
* set the orgin in BPrintJob, to be able to print more then one page properly
Note: This would make printing work on HAIKU as on BeOS, but still it does
not because of 1; BPortLink size limit and 2; because we can only print/ draw
the visible region of a view? I had to resize StyledEdit to a i.e 10000
to test and to be able to print the full syslog.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24682 a95241bf-73f2-0310-859d-f6bbb57e9c96
the current workspace.
* This should fix bug #1765 as far as the app_server is concerned.
* Cleanup, removed extraneous white space.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24632 a95241bf-73f2-0310-859d-f6bbb57e9c96
style couldn't be found, ie. when looking for "Roman", "Regular", and
"Book" are accepted, too, and "Italic"/"Oblique" are now synonyms as
well.
* This prevents StyledEdit from using the "Condensed" style when it does
not find a certain font.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24443 a95241bf-73f2-0310-859d-f6bbb57e9c96
* It is necessary to store the local origin and scale of a view state, at
least for the clipping region and especially because the scale affects the
clipping region. Ie origin and scale of one state affect the clipping region,
at the time the clipping is evaluated, ie
SetOrigin(...);
ConstrainClippingRegion(...);
is equivalent to
ConstrainClippingRegion(...);
SetOrigin(...);
The current client provided clipping region at the time of PushState()
always constrains the region of the new state. The previous region
and the current local clipping may have their own individual origin and
scale.
To support all this, I needed to store origin and scale of each state on
the stack, but I do cache the combined origin and scale. Caching only
the combined region is not possible though. So the new implementation
is slower than the previous, but more correct.
* Refactored "copy constructor" from DrawState, which is not really a copy
constructor anyways, made it private. It is only used by PushState().
* Removed some dead code from DrawState.
All this improves Firefox redraw issues a tiny bit, but does not fix them.
Either I am not covering Firefox needs with my test app, or the bug is
somewhere else. At least Haiku behaves like BeOS with regard to client
clipping regions and the state stack now...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24428 a95241bf-73f2-0310-859d-f6bbb57e9c96
maybe this should be the assembler version we use for x86, but is probably
fine for the purpose of the test environment (only BString uses this)
* Fix semantics of DrawingEngine::CopyToFront() which I recently introduced,
for the fake accelerant of the test environment, we do need to call
Invalidate(), not CopyBackToFront() directly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24422 a95241bf-73f2-0310-859d-f6bbb57e9c96
and an invalid desktop message port...
* Desktop::Init() now checks if VirtualScreen::fHWInterface is valid, and exits
if not. This can happen if you don't have a graphics driver, and turn on on-screen
debug mode in the boot loader (such that you already see the messages from the
boot loader).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24371 a95241bf-73f2-0310-859d-f6bbb57e9c96
to take the current effective drawing region of the view, but converted to
local coordinate space. Untested as of yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24361 a95241bf-73f2-0310-859d-f6bbb57e9c96
back to front copies in Window for updates. When in an update session,
any back to front copies are turned off. When the update session ends,
the whole region is copied at once. This has two effects: For once, it
avoids a lot of unnecessary copies (for example, rendering text copied
the background and then the same area for the text again). But even more
effective, it changes the entire drawing of any Haiku app to be completely
flicker free. Provided it happens in the normal Invalidate()/Draw() cycle.
And of course all this only works for double buffering mode, ie VESA.
Potentially, I might have overlooked something, so that this patch could
result in some drawing glitches, but in my testing, I have seen none yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24354 a95241bf-73f2-0310-859d-f6bbb57e9c96
rectangle area that is touched by a drawing command.
* Added a CopyToFront(BRegion) method which copies a complete region from
the drawing/back buffer to the front buffer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24353 a95241bf-73f2-0310-859d-f6bbb57e9c96
of BDirectWindows for setups where the app_server uses double buffering mode.
I didn't test the change, but the way the cursor is optionally copied into
the bitmap (which might now be not 32 bpp) looks very flexible.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24346 a95241bf-73f2-0310-859d-f6bbb57e9c96
cleared which have no app_server link (B_BITMAP_NO_SERVER_LINK).
* Check the allocation of the BWindow in BBitmap for view accepting bitmaps.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24344 a95241bf-73f2-0310-859d-f6bbb57e9c96
instance by introducing Window::InitCheck(), use new (nothrow).
* Window is responsible for the DrawingEngine instance, but forgot to delete
it.
* OffscreenWindow is no longer special, every Window owns a DrawingEngine,
no need to delete it anymore, but since it already deletes the HWInterface
instance, it needs to detach the DrawingEngine from it.
* Use new (nothrow) in OffscreenWindow as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24308 a95241bf-73f2-0310-859d-f6bbb57e9c96
(now WorkspacesView), OffscreenWindowLayer.
* Renamed ServerScreen.cpp/h to Screen.cpp/h (the class was already called
Screen).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24303 a95241bf-73f2-0310-859d-f6bbb57e9c96
hide it (because of different argument types, BRect vs. IntRect).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24302 a95241bf-73f2-0310-859d-f6bbb57e9c96
more than one of them at the time.
* Changed ViewLayer::FindView() to FindViews() that collects all views
with the given flag set, not just the first one.
* Made ViewLayer::AttachedToWindow() and DetachFromWindow() virtual,
WorkspacesLayer now overloads them to register itself with the window and
the desktop.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24300 a95241bf-73f2-0310-859d-f6bbb57e9c96
next window to get focus after the current one is gone. This fixes the
strange behaviour when using right-click to send the current window to
the back.
* When FFM is active, Desktop::SendWindowBehind() will now choose the
new focus window to be the one under the mouse, overriding the focus
list.
* Desktop::SendWindowBehind() will now also call _SendFakeMouseMoved()
if necessary.
* Removed Desktop::fFocusFollowsMouse; it was not used or
maintained anywhere.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24269 a95241bf-73f2-0310-859d-f6bbb57e9c96
help. However it appears I might have fixed the GL apps drawing over
other windows. Cannot reproduce this problem anymore, but it may be
that this bug doesn't show on my new setup (32bit double buffered VESA).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24267 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the last focus.
* When choosing a new focus window, this list is now used to find the
new focus window instead of just choosing the next window in the
workspace list.
* With the normal mode mouse, this shouldn't change anything, but with
focus follows mouse turned on, this will behave much better if you
don't actually move the mouse - and it also fixes bug #1886.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24234 a95241bf-73f2-0310-859d-f6bbb57e9c96
parameter for the length of the arrays, so that even if the char/byte
counts do not match, no memory is overwritten anymore.
This fixes bug #1862; .canna obviously contains invalid UTF-8
characters, or there is a bug in StyledEdit (or deeper) and it doesn't
call BFont::GetEscapements() correctly.
* Fixed some cases of unchecked allocations in the font handling methods
of ServerApp, added TODOs to all other ones.
* Improved error code when creating a window fails.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24160 a95241bf-73f2-0310-859d-f6bbb57e9c96
just like Vera, but it has some more glyphs. Actually we could get rid
of Vera completely.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24143 a95241bf-73f2-0310-859d-f6bbb57e9c96
used the BRect version of HideSoftwareCursor() but then called
ShowSoftwareCursor() unconditionally.
* Renamed Hide/ShowSoftwareCursor() to Hide/ShowFloatingOverlays().
* Removed no longer needed FontLocker.
* Implemented AutoFloatingOverlaysHider and got rid of a lot of
code duplication this way.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24095 a95241bf-73f2-0310-859d-f6bbb57e9c96
workspaces view can now be any view in the hierarchy.
* Added private view flag kWorkspacesViewFlag that identifies such a
view - note though, that you must not remove a view before closing or
hiding its window for now (and that you still need to set the
kWorkspacesWindowFlag, too).
* Fixed Workspaces check for valid screen coordinates; after a crash, it
managed to open its window offscreen for me.
* Added a ViewLayer method FindView() that finds a view with the
specified flags set.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24090 a95241bf-73f2-0310-859d-f6bbb57e9c96
was not used in case of 32 bit VESA modes. Gives a huge performance boost
for 32 bit VESA mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24084 a95241bf-73f2-0310-859d-f6bbb57e9c96
should prevent the app_server to send any update messages to the client. It
should just keep adding to the pending update sessions region until the client
enabled updates again. If anything is already in the pending session, an
update request will be send immediately.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24029 a95241bf-73f2-0310-859d-f6bbb57e9c96
entire screen when exiting the kernel debugger. It sets up a thread that sends
a message to the (currently hardcoded) desktop message looper. The desktop then
does mark the whole screen dirty which causes a full redraw.
Since interrupts need to be enabled I went with an asynchronous thread and
releasing a request sem in the add-ons' exit hook.
Added the add-on to the image as it shouldn't hurt to have it for now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24025 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Since it didn't check if any mouse button was pressed at the time it was
called, it would still initiate a drag, and thus caused bug #1710.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23782 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Our behaviour differs a bit from how BeOS handles those windows, added a
comment to the code which explains that, and how we could change it if we
really wanted to.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23705 a95241bf-73f2-0310-859d-f6bbb57e9c96
views don't have a valid screen clipping yet. If then later we want
to invalidate the clipping of an entire hierarchie, the traversal stops
before reaching some of the child views, because the assumption was that
for any views with invalid screen clipping, their child views have invalid
screen clipping as well. Though this might cost a little performance, we
always invalidate the screen clipping of all child views, ignoring the
flag of the current view. Fixes ticket #1198 (garbled screen clipping of
E-Mail prefs and WonderBrush tool area when switching tabs).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23688 a95241bf-73f2-0310-859d-f6bbb57e9c96
in question as it used to find the view that is under the mouse (found
during a short phone session with stippi :-)). This fixes bug #1714.
* The local view clipping is still not correctly maintained by the
app_server, but that only affects the drawing now. I've added some
commented out code that give you some visual feedback on this problem
(ViewLayer::MarkAt()).
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23663 a95241bf-73f2-0310-859d-f6bbb57e9c96
* If two intersecting windows didn't change their position but their
order, the dirty region wouldn't contain the region that would need
to be updated because of that order change. This fixes bug #827.
* When a hidden window was on the new workspace (but not on the old one),
its region would be included in the dirty region, but shouldn't have
been. This caused the app_server to update a larger region than
necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23398 a95241bf-73f2-0310-859d-f6bbb57e9c96
This fixes the bug described by Stefano in r23343.
* Therefore, I enabled cached menu windows again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23356 a95241bf-73f2-0310-859d-f6bbb57e9c96
mouse events would not be passed to the correct children of views with
B_DRAW_ON_CHILDREN flag set -> fixed. (fixes#1673)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23300 a95241bf-73f2-0310-859d-f6bbb57e9c96
by toggling pointers instead of assigning/transfering regions
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23272 a95241bf-73f2-0310-859d-f6bbb57e9c96
* cleanup the code in a few places
* fixed a bug where the border region would not be made empty if there
was a decorator previously, but there is no new one
* slight improvement for memory footprint of WindowLayer by using bit fields
for more of the flags
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23271 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed bitmap fonts for real (applied the wrong patch last time)
* some cleanup for coding style by myself (in other places)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23269 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed rendering of certain chinese fonts
(I think it fixes rendering of bitmap fonts in general, but it should not
support rotated text AFAIKT, since that is only supported for vector fonts)
Nice work, Anthony, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23261 a95241bf-73f2-0310-859d-f6bbb57e9c96
* improved naming of some private BView functions and used our underscore
prefix
* added a _DrawAfterChildren method to BView which does the necessary setup
and calls the DrawAfterChildren hook
* call the new _DrawAfterChildren method in the BWindow implementation, this
was easy since the view tokens are already hierachically sorted
* implement support for B_DRAW_ON_CHILDREN in the app_server's ViewLayer, it
simply means that children are ignored for the views clipping region, any
drawing methods will paint over children (therefor the B_DRAW_ON_CHILDREN
flag is even properly named)
With these changes, support for B_DRAW_ON_CHILDREN and the DrawAfterChildren()
hook are implemented and behave exactly as on R5 as far as I can tell, also
for the view background painting.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23154 a95241bf-73f2-0310-859d-f6bbb57e9c96
position on screen (fixes drawing glitches in patterns when the view
was moved on screen (for example because the parent window got moved))
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23089 a95241bf-73f2-0310-859d-f6bbb57e9c96
Update the menu_info neverthless, when setting the ui_color for menu
backgrounds. Fixes bug #550.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23070 a95241bf-73f2-0310-859d-f6bbb57e9c96
Still needs code to save the values.
Also needs a way to access them from Decorator::UIColor(), but the DesktopSettings passed to the ctor can't be cached.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23024 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Reduced rating of the color space - after all, the resolution is more
important.
* The EDID detailed modes are now scanned for the best mode available, this
could be done in various ways, so please report any problems you have with
it.
* Ignore resolutions below 640x350 - this should also fix bug #1615.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22908 a95241bf-73f2-0310-859d-f6bbb57e9c96
the timing of the original mode into account (I haven't tested if the computed
score makes that much sense, though).
* GetPreferredMode() now also works correctly for EDID data): it now returns
the correct status, and also constructs the mode correctly. Furthermore, it
will now search for the mode in the mode list, instead of using that mode
directly (so that it can take hardware limits into account).
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22778 a95241bf-73f2-0310-859d-f6bbb57e9c96
this information in the fValidClipping flag... which should prevent
any drawing code to run if Painter is not attached properly
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22736 a95241bf-73f2-0310-859d-f6bbb57e9c96
it can happen that a view's background region is outside the
framebuffer... for some weird reason, it doesn't get triggered
though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22725 a95241bf-73f2-0310-859d-f6bbb57e9c96
falls within the frame buffer bounds. This should not happen, and
I am going to search for the cause next, but at least app_server
dosn't crash anymore in this context. Left a comment on my findings
so far.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22721 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Named settings are only overwritten if they were an exact match (ie. it's
the very same monitor).
* The unnamed settings retrieval now has two passes, on the first it will
now ignore named settings. It will also only remove unnamed settings now.
* Added some TODO commments.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22632 a95241bf-73f2-0310-859d-f6bbb57e9c96
just the frequency.
* Previously saved modes are no longer supported, though.
* Screen modes are now stored with the monitor info it belongs to, IOW the
app_server will now choose a mode from the settings that fit your monitor
description. Driver support is required for this to work as intended.
* The changes are completely untested at this point, though, sorry (shouldn't
harm anyone, though) :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22622 a95241bf-73f2-0310-859d-f6bbb57e9c96
* in r22410 the unlock/relock was removed accidently from ServerWindow::_Hide()
before calling a desktop method.
* Desktop::ActivateWindow() no longer calls SetWorkspace() with the window lock
held.
* WorkspacesLayer::MouseUp() now uses the asynchronous version of SetWorkspace().
* AFAICT AS_HIDE_WINDOW, AS_SHOW_WINDOW, and AS_MINIMIZE_WINDOW don't need the
all window lock, reverted to standard single window lock.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22614 a95241bf-73f2-0310-859d-f6bbb57e9c96
working with it. The app_server would have crashed before if a graphics driver
could directly return a preferred display mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22595 a95241bf-73f2-0310-859d-f6bbb57e9c96
accelerant (or the app_server via EDID info). It's still experimental
API, and opinions are welcome.
* Moved BPrivateScreen into the BPrivate namespace.
* Rewrote Screen.h.
* Introduced a BScreen::GetMonitorInfo() method, and implemented it in the
app server as well (ie. AS_GET_MONITOR_INFO).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22563 a95241bf-73f2-0310-859d-f6bbb57e9c96
implemented; it now only returns wether or not the window is part of the
list specified by the index. This fixes bug #195 and #1553.
* HasInSubset() would report "true" for app-floating windows vs. modal app
windows which was wrong.
* Removed SameSubset() as it isn't needed at all.
* SubsetWorkspaces() now take the front window into account for floating
windows.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22549 a95241bf-73f2-0310-859d-f6bbb57e9c96
the accelerant, as well as its EDID info. B_GET_PREFERRED_DISPLAY_MODE and
B_GET_EDID_INFO are both optional. The preferred mode will be taken from the
EDID info if only the latter hook is implemented, or the former returned an
error.
* Currently, the app_server should correctly set the preferred mode on start,
but no accelerant supports that yet, so it's not really tested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22520 a95241bf-73f2-0310-859d-f6bbb57e9c96
of locking before processing the message (single/all window lock)
-> in most message cases, I could comment out the unlocking/locking which
switched to the different lock, because the required lock is now already held,
this removes some race conditions which were commented in the code already
* EventDispatcher::SetDragMessage() didn't lock the object, this would have
been bad if multiple windows tried to set a drag bitmap at once
* the Desktop object keeps track of mouse position and pressed buttons, so
that it doesn't need to lock the EventDispatcher for sending fake mouse
moves to windows on show/hide of windows (solves some cases of possible
dead locks with the new locking strategy)
* the keyboard EventFilter switches the current workspace asynchrnously from
the Desktop thread (another source of possible deadlocks)
* the "reader is trying to become writer" check in MultiLocker is only used
in DEBUG mode now
As a summary: It would be nice if ServerWindow used a readlock for all messages
it processes itself, and forwards all messages for which it needs a write lock
to the Desktop thread. All cases where either the Desktop or the ServerWindow
mess with the EventDispatcher are possible sources of deadlocks. This is solved
right now by making sure that the lock is released before using the
EventDispatcher.
I have not observed any deadlocks while switching workspaces and launching
many apps anymore, neither crashes. But I have not tested extensively except
for in the test environment. That being said, I could reproduce the problems
on first try before in Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22410 a95241bf-73f2-0310-859d-f6bbb57e9c96
client and the server. This should fix bug #1490, but I haven't tested it yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22388 a95241bf-73f2-0310-859d-f6bbb57e9c96
by now, I feel there is too much code involved in this... I guess I should
really move this to stuff to ViewLayer::ConvertToScreenForDrawing()...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22223 a95241bf-73f2-0310-859d-f6bbb57e9c96
* put message codes for Begin/EndRectTracking() into giant switch... not
actually implemented though
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22220 a95241bf-73f2-0310-859d-f6bbb57e9c96
needs to be recalculated when the scale changes.
Also call ResyncDrawingState() in exit_state_change(). This fixes the
pen size test in FlattenTestPicture.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22215 a95241bf-73f2-0310-859d-f6bbb57e9c96
always put between window screens and modal all windows (before floating
all ones), so a BWindowScreen couldn't have menus at all.
Now, they behave more like floating app windows, just that they float above
all other application windows, such that all window feels (also BWindowScreen)
can now have menus.
* Reenabled keyboard redirection to the top most window in case it's a menu;
bug #1152 no longer applies due to the above change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22149 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Since the app_server launched the input_server, it would also get notified
when the latter died via a signal - but LinkReceiver could return B_INTERRUPTED
in that case (it didn't check the return value of port_buffer_size()) which
the app_server misinterpreted and quit itself... this fixes the hanging part
of bug #1298.
* But the input_server still wasn't restarted, because the Registrar had it
still listed as being running. Now, the Registrar checks not just periodically
for died teams, it will also check for it when a new application registers
itself. This fixes the rest of bug #1298.
* Removed the old (disabled) R5 style input_server launch mechanism from the
app_server.
* MessageLooper now prints a bit more information when a port is supposed to
have been deleted.
* The default implementation of MessageLooper::_GetLooperName() is now
returning the name of the semaphore of its BLocker instead of "unnamed
looper".
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22115 a95241bf-73f2-0310-859d-f6bbb57e9c96
have become more expensive, so maybe it is better to do what I proposed
in the ticket comments, and move the rounding of drawing command coordinates
into ViewLayer::ConvertToTopForDrawing() instead of handling it in
DrawingEngine and Painter
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22060 a95241bf-73f2-0310-859d-f6bbb57e9c96
possibly making them a little faster too
* mess with decorator button size calculation to make the whole layout scale
more agreeable with the font size (no more fixed offsets/insets), but it
is work in progress
* DefaultDecorator no longer allocated the border color array, it is part of
the object now
* small memory footprint optimizations in ViewLayer, Decorator and WindowLayer
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22003 a95241bf-73f2-0310-859d-f6bbb57e9c96
* origin is given in "outer" coordinate system therefore if there is a
previous state it has to be transformed. Please review if this is
required in OffsetOrigin() too.
* in Transform() we have to scale relative to the view origin not (0 /
0).
- optimized SetScale: saved one division
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21993 a95241bf-73f2-0310-859d-f6bbb57e9c96
as Marcus pointed out, having it outside wasn't thread safe. Moved
PicturePlayer into the BPrivate namespace.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21982 a95241bf-73f2-0310-859d-f6bbb57e9c96
* after this change, I have not spotted "left behind" cursors again, but it
might just be bad luck...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21966 a95241bf-73f2-0310-859d-f6bbb57e9c96
PicturePlayer to explain what we need to do. Don't write the
B_PIC_ENTER_STATE_CHANGE and B_PIC_ENTER_FONT_STATE ops until we fix the
problem (we don't care about them in our server side
implementation anyway). Font changes and state syncing work again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21940 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the function table, so if someone passes a smaller table, we avoid
calling invalid pointers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21939 a95241bf-73f2-0310-859d-f6bbb57e9c96
maybe this is too resource hungry, feel free to critisize... :-)
* the speedup is there, but not overwhelming
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21929 a95241bf-73f2-0310-859d-f6bbb57e9c96
AppendToPicture() (but still doesn't work :( ). Moved some functions
around in PictureDataWriter.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21925 a95241bf-73f2-0310-859d-f6bbb57e9c96
kept in a list by ServerApp, and deleted by its destructor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21924 a95241bf-73f2-0310-859d-f6bbb57e9c96
stroke/fill polygon, stroke/fill bezier. some work towards drawing of
nested pictures.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21918 a95241bf-73f2-0310-859d-f6bbb57e9c96
* revised use of check_lock() versus do_owner_check() (do_owner_check()
is supposed to drop you into the debugger if there is no owner, otherwise
it behaves like check_lock())
* ConstrainClippingRegion() no longer transmits empty regions to the
app_server. I would have thought that my fix to ServerLink would have
solved the issue I was investigating, but only this commit fixes it.
Maybe the last commit would have fixed it if I did a "jam clean"...
* WonderBrush draws the icons again on mouse over...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21910 a95241bf-73f2-0310-859d-f6bbb57e9c96
BView implementation (client side)
* introduced some private methods for _Convert*(BPoint*) methods which avoid
doing the check_lock() thing in the recursion, also Origin() would likely
have communicated with the app_server all the time, since the origin bit
was needlessly invalidated, so some speedup should be achieved
* this should fix ticket #98
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21900 a95241bf-73f2-0310-859d-f6bbb57e9c96
implementation takes the byte count, even though it looks like this is
less efficient when the glyph count is already known (I tested to
optimize it away but it was not faster)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21891 a95241bf-73f2-0310-859d-f6bbb57e9c96
Painter, that is needed to be able to tell if anti-aliasing is to be used,
since the flags in the font can be overruled by the flags in the view...
* fixes aliased fonts reliably, tested with FontDemo
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21869 a95241bf-73f2-0310-859d-f6bbb57e9c96
this for a long time... what happens when the app_server has requested a
redraw, but the client sends some drawing commands before starting the
redraw session? This would be the case, for example, when TextViews got
notified of their parent window becomming active (they would invert the
selection outside of any update session). When there was an additional
expose event, the app_server would already have the background cleared, so
the lonely "invert" command would invert the freshly painted background. Then
the normal Draw() of the TextView would be called because of the expose event.
By the time the text was rendered, it was rendered on the inverted background,
then the normal Draw() contained another "invert" command to invert the
region of the selection. Thus inverting just the text, and the background
twice. Solution:
* introduced a special handling for drawing commands arriving between
requested update session and beginning of that session: the pending
update region is clipped from the region the client is allowed to draw in.
* fixes funny text rendering in the selected part of text views. For example
ticket #908.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21867 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fixed a bug in the font cache, the signature was generated in one way
(rendering type) while the initialization of the font engine could
use another way
* should fix non-antialiased straight text
* weird non-transformed text in FontDemo
* generally not using vector glyphs when it was supposed to use them (rotated
or sheared text, or non-antialiased text)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21866 a95241bf-73f2-0310-859d-f6bbb57e9c96
(fixes ticket #1367, stefano I thought you knew that I meant this in an
earlier mail)
* move_pen_by() looked wrong in ServerPicture, have not tested though
* make sure the pen location is adjusted after stroke_line() and draw_string()
in ServerPicture
* set_pen_location() does not need to update the Painter drawing state
* ServerWindow AS_LAYER_SET_PEN_SIZE needs to set the resulting pen size of
the drawing state stack, not the one set on the current state
* ServerWindow AS_LAYER_GET_PEN_SIZE needs to return the current state's
size, not the result of the stack
* small cleanups
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21855 a95241bf-73f2-0310-859d-f6bbb57e9c96
and that the previous pattern is restored after execution
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21853 a95241bf-73f2-0310-859d-f6bbb57e9c96
ServerFont::GetBoundingBoxesForStrings() (ScreenSaver no longer crashes as reported by Brian
Verre on the mailing list).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21846 a95241bf-73f2-0310-859d-f6bbb57e9c96
and then use hardware acceleration... found out this is what our
BTextView is actually using, that's why it never used hardware
acceleration for invert rect/region before. Have not tested this on
real hardware yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21843 a95241bf-73f2-0310-859d-f6bbb57e9c96
a BPicture, though I'm not yet sure if I should do it there on when
playing the picture...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21836 a95241bf-73f2-0310-859d-f6bbb57e9c96
offset works correctly. Drawing a BShape using a BPicture is currently
broken. Stephan, any insight on what it's changed about shape drawing ?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21835 a95241bf-73f2-0310-859d-f6bbb57e9c96
