shutdown process is entered (ie. you cannot start new applications anymore),
I changed its window feel to normal to make it possible to let it appear on
all workspaces.
* We should think about if simply letting it enter that phase later isn't the
better solution, though. Opinions welcome.
* Automatic whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27830 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added icon to the registrar.
* Updated copyright years in version info.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27824 a95241bf-73f2-0310-859d-f6bbb57e9c96
icon a little clearer.
* Applied icon to MediaServer rdef. Removed original BeOS icons. Updated
copyright years.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27815 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use std::nothrow (the rest of the file already used it).
* We also have to keep the source file around and properly dispose it, as
OffsetFile doesn't take ownership of it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27486 a95241bf-73f2-0310-859d-f6bbb57e9c96
still be NULL although it is used further down.
* CID 526: Check the front buffer to be available before using it in SetMode().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27483 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note that this file has a completely different coding style, violating ours for
consistency until the whole file can be cleaned up.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27480 a95241bf-73f2-0310-859d-f6bbb57e9c96
since fPageFormatText is accessed in both branches of the if before the null
check. If it was actually null there would be a crash well before line 483. In
addition this member is initialized in the constructor. I assume the null check
was added to provide symmetry with the null check of fJobSetupText below it.
But that latter null check is needed since fJobSetupText may not have been
created in the constructor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27427 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
