a user resize, this makes ArtPAint's tool pallete window resize properly
Thanks Stephan for explaining me two time what to look for :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27384 a95241bf-73f2-0310-859d-f6bbb57e9c96
is called after BeginPicture on a freshly created view.
This is necessary because a second invocation on this view with BeginPicture
would have caused ServerPicture::SyncState to write the default drawing state
into the picture. This happens because to BView had now cached the values and
therefor won't go to the app_server and tell about the change. The first call
did not change anything as picture recording is handled in _DispatchPictureMessage
while view changes that modify drawing state are handled in _DispatchViewMessage,
thus leading to default draw state values beeing written.
This fixes invalid ticket #2534.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27218 a95241bf-73f2-0310-859d-f6bbb57e9c96
this makes printing of large images work, fixes task #1067
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27214 a95241bf-73f2-0310-859d-f6bbb57e9c96
retrieve CDDB information. This is coming as soon as I have real time (as
opposed to some minutes during lunch) to work on it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27200 a95241bf-73f2-0310-859d-f6bbb57e9c96
a regression in MediaPlayers peak display where the last row of pixels was
wrong.
* Fixed clipping rect bugs in the new bilinear scaling loops, the last row
and/or columns don't always need special treatment, only if they map to the
last row and/or column of the destination bitmap.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27177 a95241bf-73f2-0310-859d-f6bbb57e9c96
nearest neighbor scaling, I noticed that the bilinear version
actually used less CPU than the generic AGG code path with nn
scaling. So I wrote an optimized nn scaling routine for nn
based on the bilinear scaling code. So the indices into the
source bitmap are cached. I don't know if this is the optimal
nn scaling routine, but the CPU usage dropped significantly.
Only B_OP_COPY is optimized as of yet.
* Optimized the bilinear scaling. When more filtered pixels than
unfiltered pixels are anticipated, the loops are unrolled to
special case the very last row/column and bottom right pixel.
This eliminates the branches in the loops.
* Fixed a bug with partial scaled drawing of bitmaps when it
used the bilinear scaling, the bitmapShift was in the wrong
direction.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27169 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Includes all relevant handling of CDDA exported attributes so you guys can
see where I am going with this.
CDDB handling (including server connection, request and response parsing)
will come up next. In the future we will also have a configuration panel
and a Deskbar replicant for controlling it.
Do we really have to edit the Jamfile in the parent dir to get something
building with our build system?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27096 a95241bf-73f2-0310-859d-f6bbb57e9c96
will need to write lock the window lock, we cannot call it with the read
lock held.
* Added a TODO comment in _ActivateApp() on how we could handle minimized
windows.
* Added a WindowList::Count() method.
* Added a WindowList::ValidateWindow() that you can use to validate a window
pointer in case you had to unlock the list.
* Made FirstWindow()/LastWindow() const.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26957 a95241bf-73f2-0310-859d-f6bbb57e9c96
get_window_order() will retrieve the application respectively window order
on the selected workspace.
* Moved private BeOS compatible functions (as used by the Deskbar) into the
private WindowInfo.h header.
* Whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26951 a95241bf-73f2-0310-859d-f6bbb57e9c96
* It will now first iterate through the windows on the current workspace to
choose the topmost window of this team (for this, it would be nice to have
a sorted list over all windows/workspaces).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26950 a95241bf-73f2-0310-859d-f6bbb57e9c96
about. ServerWindow::GetInfo() now fills in that value following this logic
as well as further testing.
* Whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26942 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
* adjust all drivers to take that into account
* fix UpdateText() signature in JSDSlider to avoid warning
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26648 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Fix PincodeWindow to send the pincode commands dissapear after clicking
- Improve the debug output of bluetooth_server
- Handle all needed events for the pairing
- Simple request could send and receive the event before adding the request to the events wanted list. Inverted the order of this sequence.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26614 a95241bf-73f2-0310-859d-f6bbb57e9c96
* move libprint headers into libs headers folder accordingly
* merge all shared folders sources into kits print, we might build later on a
real print kit, propably also to access cups from an nicely API, atm static
* move all shared headers into private print, also pr_server.h from interface
* adjust build to work with the changed folder layout
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26570 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
- Rename event structures to be consistent with another remaining ones
- Fix typos
by Mika & Oliver
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26476 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
mouse messages have a "when" field with the event system time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26328 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
Report the index where the event opcode pair has been found.
Currently server was expecting them to be the first entry of the request
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26198 a95241bf-73f2-0310-859d-f6bbb57e9c96
Avoid unhandled event in the bluetooth_server
by Mika Lindqvist
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26196 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
