* The maximum vector icon data size was a bit low. That may
be hard to track down why a certain vector icon doesn't work,
especially when imported from SVG...
* Don't allocate the vector buffer on the stack anymore.
Bug introduced in 810f0a42e5.
The uint8 cast were also acting as masks for each of the pixel
components, moving them out of the multiplications made things go wrong.
Use rgb_color instead of messing with bitshifts and masks for better
readbility (the colors are out of order, but the processing is the same
on each color so the end result is valid).
* Support downscaling icons to a size smaller than the source.
* For > 4x icon scaling do a scale4x followed by a bilinear scale.
Note that I tried to do a combination of scale2x/scale3x with bilinear scaling
and the results were worse than scale2x/scale3x with down scaling.
The 24x24 icon case looks pretty bad either using bilinear or scale2x followed
by a downscale because I am currently upscaling the 16x16 icon in Deskbar (we
didn't up until now support bitmap icon downscaling so I had no choice). It
might be a better idea to downscale the 32x32 version instead.
Note that all of the above has to do with bitmap icons ONLY and none of it
applies to HVIF icons that scale beautifully without these tricks.
Implemented a simple down sampling algorithm in the scale_down() function. For
non-integer scaling first scale up using the scale2x, scale3x, or scale4x
algorithm doubling, tripling, or quadrupling the icon then use the downscaling
algorithm to shrink to the desired size. This produces nicer looking results
than bilinear scaling alone.
Note that this only applies to bitmap-based BeOS icons and not vector-based
HVIF icons.
Refactor the icon scaling code in IconUtils.cpp to avoid code
duplication. Basically create and delete the temp bitmap to
convert from B_CMAP8 to B_RGBA32 for scale2x/scale3x/scale4x
just one time instead of 3.
There was an off-by-one error in Deskbar which was causing
it to scale up the 16x16 Bitmap icon to 32x32 instead of just
using the 32x32 icon. This only affected BeOS bitmap-based
icons, not Haiku HVIF icons.
* rename B_TRANSLATE_CONTEXT to B_TRANSLATION_CONTEXT and
B_TRANSLATE_WITH_CONTEXT to B_TRANSLATE_CONTEXT, squashing a TODO
* adjust all uses of both macros in Haiku's source tree
* use correct header guard for collecting/Catalog.h
The renamed macros require adjustments to all external applications
using catalogs.
icon scale is larger than the maximum visibility scale of
4.0f. This just means you cannot prevent shapes from
rendering in icons rendered larger than 256x256.
visibility scale is 4.0
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41206 a95241bf-73f2-0310-859d-f6bbb57e9c96
and uses it when old B_CMAP8 icons are to be upscaled exactly 2x. Looks much
better than the previous blurry bilinear scaling. Small cleanups by myself,
closes#7130, thanks a lot!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40678 a95241bf-73f2-0310-859d-f6bbb57e9c96
a translator as well, this might just be expected.
* Minor style cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39418 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Replaced all occurences with the standard macros M_PI, and M_PI_2.
* Some coding style cleanup on the touched files, no other changes besides
adding a missing check for a failed memory allocation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31250 a95241bf-73f2-0310-859d-f6bbb57e9c96
BIconUtils to understand and render it. This makes it possible to use the
HVIFTranslator to also read Icon-O-Matic files out of the box. Will cleanup
now duplicated files next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30794 a95241bf-73f2-0310-859d-f6bbb57e9c96
Renamed BGradient::color_step to BGradient::ColorStop
as it's called everywhere else. Also renamed BGradient::gradient_type
to just BGradient::Type. Renamed BGradient::Type() to GetType().
* Simplification of method names in Painter.cpp. Some not yet
complete and yet inactive code to accelerate vertical gradients
(bypassing AGG for this special case).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29214 a95241bf-73f2-0310-859d-f6bbb57e9c96
class/namespace. Renamed the B_GRADIENT_* types to TYPE_* as the context
is already given.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28564 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented BGradient, BGradientLinear, BGradientRadial,
BGradientDiamond, BGradientConic and BGradientRadialFocus
new Interface Kit classes.
* Implemented all the (AGG-based) backend necessary in
the app_server to render gradients (Painter, DrawingEngine)
* app_server/View can convert a BGradient layout to screen
coordinates.
* Added BGradient methods of the Fill* methods in BView.
* Implemented a test app and added it to the image as a
demo.
* Adopted Icon-O-Matic and libs/icon in order to avoid
clashing with the new BGradient class. Re-use some
parts where possible.
Awesome work, Artur! Thanks a lot. Now a more modern
looking GUI has just become much easier to implement! :-)
TODO:
* Remove the need to have gradient type twice in the
app_server protocol.
* Refactor some parts of the patch to remove duplicated
code (Painter, DrawingEngine).
* Adopt the BPicture protocol to know about BGradients.
* Review some parts of the BArchivable implementation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28109 a95241bf-73f2-0310-859d-f6bbb57e9c96
transform only, not combined with the shapes own scale, since that is likely
not what the user intended.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25521 a95241bf-73f2-0310-859d-f6bbb57e9c96
style uses has an alpha value below 255.
* Add support for intermediate rendering passes to IconRenderer. Normally,
the whole icon is rendered in a single pass, which means shapes cannot
overlap. With the change, intermediate rendering passes are inserted when
a shape is encountered that contains transparency. This is an easy way to
allow for more feature rich icons, with easy support for glossy/reflective
surface effects or other such effects that require support for transparent
shapes on top of other shapes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24490 a95241bf-73f2-0310-859d-f6bbb57e9c96
not negative
* PathSource can now remember a global scale, and the IconRenderer sets
it, since this value is used in the curve converter for on the fly
generation of vertices, this change does not affect anything and doesn't
create the need to "update" the conversion pipeline to render an icon at
different sizes (like Icon-O-Matic does)
-> this change fixes edgy curves on icons rendered bigger than 64x64 as
reported by Axel some time ago
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23093 a95241bf-73f2-0310-859d-f6bbb57e9c96
error if the provided bitmap was B_CMAP8, now BIconUtils will convert the
icon to B_CMAP8
-> this behaviour is a little inconsistent compared to what happens when
reading icons from attributes, there, the CMAP8 icon is prefered in case
such a bitmap is passed, even if a vector icon exists. I am not really
sure which behaviour is better. For a consistent UI, maybe it is better
to prefer the vector icon always. I've added a note to BAppFileInfo.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22414 a95241bf-73f2-0310-859d-f6bbb57e9c96
and the mechanism to prevent them not working...
* could have fixed the "there are still listeners attached" bug (debugger drop)
on exit, I have not seen it again, but I am not sure if it is really fixed
* introduced a way to ask the user, if changes should be saved and then
pick up the line of thought after saving
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22269 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Minor cleanup (like removing the extra blank line between the copyright and the
header guard).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20507 a95241bf-73f2-0310-859d-f6bbb57e9c96
solves the problem that app_server uses the wrong version of
the class
* TODO: put all the other classes into this namespace as well,
I'm just eager to close this crucial bug, which Ingo kindly
tracked down
[darn, this commit stalled before, and I commited the next step
already from another Terminal...]
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20481 a95241bf-73f2-0310-859d-f6bbb57e9c96
there is some unfortunate code duplication in AppFileInfo,
because it cannot use BMimeType/BNode alone to retrieve icons,
now it works closer to the code in BIconUtils, this fixes
R5 icons not displaying for other icon sizes
* implemented a bilinear scaling function, I don't know if
it is very fast, but I hope it is reasonable. Now that I
see the results though, I wonder if R5 icons should be
scaled with nearest neighbor instead...
* corrected a small bug in the icon format stuff...
7 bit coords are -32-+95, not 96
* improved comment for BIconUtils function
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19302 a95241bf-73f2-0310-859d-f6bbb57e9c96
