Searched hist:877 (Results 1 - 11 of 11) sorted by relevance

/haiku/data/artwork/icons/
H A DServer_MailDaemondiff 877f6bea Fri Oct 10 13:14:20 MDT 2008 Stephan Aßmus <superstippi@gmx.de> zuMi was at it again and created a cool icon for the mail_daemon. Almost a pity
to use this gem for a background application. :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27958 a95241bf-73f2-0310-859d-f6bbb57e9c96
877f6beaec6ac212b84059b01f8a8c6309419e7d Fri Oct 10 13:14:20 MDT 2008 Stephan Aßmus <superstippi@gmx.de> zuMi was at it again and created a cool icon for the mail_daemon. Almost a pity
to use this gem for a background application. :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27958 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/servers/mail/
H A Dmail_daemon.rdefdiff 877f6bea Fri Oct 10 13:14:20 MDT 2008 Stephan Aßmus <superstippi@gmx.de> zuMi was at it again and created a cool icon for the mail_daemon. Almost a pity
to use this gem for a background application. :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27958 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 877f6beaec6ac212b84059b01f8a8c6309419e7d Fri Oct 10 13:14:20 MDT 2008 Stephan Aßmus <superstippi@gmx.de> zuMi was at it again and created a cool icon for the mail_daemon. Almost a pity
to use this gem for a background application. :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27958 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/add-ons/kernel/debugger/demangle/
H A Dgcc2.cppdiff 877d64ee Wed Jul 29 04:50:43 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * The gcc2 demangler didn't like functions without any arguments.
* first_argument() never returns NULL, so we don't have to check for it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31899 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 877d64eeb1003f71d7c32788598c1f293331270f Wed Jul 29 04:50:43 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * The gcc2 demangler didn't like functions without any arguments.
* first_argument() never returns NULL, so we don't have to check for it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31899 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/data/ids/
H A Dusb.idsdiff 877d731e Wed Sep 09 21:20:36 MDT 2015 Automatic Committer <autocommitter@haiku-os.org> Update usb.ids from www.linux-usb.org
diff 877d731e03ac1163a02f96fe65903f112f2a024e Wed Sep 09 21:20:36 MDT 2015 Automatic Committer <autocommitter@haiku-os.org> Update usb.ids from www.linux-usb.org
/haiku/src/servers/app/drawing/Painter/drawing_modes/
H A DPixelFormat.hdiff 57e24888 Sun Jan 13 03:04:37 MST 2019 Stephan Aßmus <superstippi@gmx.de> Get rid of special B_OP_COPY implementation for rendering text

Since BeOS had no anti-aliased drawing except for text, it didn't
matter whether drawing diagonal lines (for example) in B_OP_COPY
or B_OP_OVER. Applying the meaning of B_OP_COPY strictly to everything
else would have broken pretty much every existing BeOS, resulting
in broken drawing for anything but straight lines and rectangles.
The solution was to treat B_OP_COPY just like B_OP_OVER *except*
for text rendering, where we could be compatible with the BeOS
behavior. Nevertheless, one can sometimes observe apps using B_OP_COPY
where they /should/ be using B_OP_OVER for rendering text, resulting
in white edges around the glyphs where the actual LowColor() does not
match the current background on which the text is rendered.
There is however a problem when glyphs in a string overlap. Some
fonts have overlapping glyphs by default (handwriting, etc). With
the LCD sub-pixel filtering, this problem is visible even in fonts
where glyphs don't overlap normally, for example 'lt'. The leftmost
pixel of the 't' is smeared due to the filtering and produces an
almost transparent pixel which is rendered (using the low color as
the background) on top of the 'l'. To fix this, one would have to
render the string into an alpha mask buffer first, and then blend it
all at once using B_OP_COPY. This however defeats the point of
B_OP_COPY, which is to be a performance optimization. So instead, I
opted for the solution that is already in place for everything else,
which is to make B_OP_COPY behave like B_OP_OVER. For the case that
this would have produced a difference, i.e. rendering with the solid
high color, one needs to clear the background using the low color,
before rendering text, or it would have looked broken. So in practice,
there cannot be a difference.

Change-Id: I4348902ae754507f1429e0a9575f03d8ecbce333
Reviewed-on: https://review.haiku-os.org/c/877
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
H A DPixelFormat.cppdiff 57e24888 Sun Jan 13 03:04:37 MST 2019 Stephan Aßmus <superstippi@gmx.de> Get rid of special B_OP_COPY implementation for rendering text

Since BeOS had no anti-aliased drawing except for text, it didn't
matter whether drawing diagonal lines (for example) in B_OP_COPY
or B_OP_OVER. Applying the meaning of B_OP_COPY strictly to everything
else would have broken pretty much every existing BeOS, resulting
in broken drawing for anything but straight lines and rectangles.
The solution was to treat B_OP_COPY just like B_OP_OVER *except*
for text rendering, where we could be compatible with the BeOS
behavior. Nevertheless, one can sometimes observe apps using B_OP_COPY
where they /should/ be using B_OP_OVER for rendering text, resulting
in white edges around the glyphs where the actual LowColor() does not
match the current background on which the text is rendered.
There is however a problem when glyphs in a string overlap. Some
fonts have overlapping glyphs by default (handwriting, etc). With
the LCD sub-pixel filtering, this problem is visible even in fonts
where glyphs don't overlap normally, for example 'lt'. The leftmost
pixel of the 't' is smeared due to the filtering and produces an
almost transparent pixel which is rendered (using the low color as
the background) on top of the 'l'. To fix this, one would have to
render the string into an alpha mask buffer first, and then blend it
all at once using B_OP_COPY. This however defeats the point of
B_OP_COPY, which is to be a performance optimization. So instead, I
opted for the solution that is already in place for everything else,
which is to make B_OP_COPY behave like B_OP_OVER. For the case that
this would have produced a difference, i.e. rendering with the solid
high color, one needs to clear the background using the low color,
before rendering text, or it would have looked broken. So in practice,
there cannot be a difference.

Change-Id: I4348902ae754507f1429e0a9575f03d8ecbce333
Reviewed-on: https://review.haiku-os.org/c/877
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
/haiku/src/add-ons/kernel/file_systems/iso9660/
H A Dkernel_interface.cppdiff d02cde30 Fri Sep 12 18:06:59 MDT 2008 Michael Lotz <mmlr@mlotz.ch> CID 877: Fix memory leak in error case.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27467 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff d02cde3053be75589a08149100011a9f73e6e966 Fri Sep 12 18:06:59 MDT 2008 Michael Lotz <mmlr@mlotz.ch> CID 877: Fix memory leak in error case.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27467 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/preferences/keymap/
H A DKeymapWindow.cppdiff 877c1bc7 Mon Feb 25 07:39:22 MST 2008 Alexandre Deckner <alex@zappotek.com> * more style cleanup


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24116 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 877c1bc7fb85a3439f3627303574288f1a18f039 Mon Feb 25 07:39:22 MST 2008 Alexandre Deckner <alex@zappotek.com> * more style cleanup


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24116 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/add-ons/kernel/drivers/graphics/nvidia/
H A DUPDATE.htmldiff 877ed9ed Tue Oct 23 13:57:21 MDT 2007 Rudolf Cornelissen <rudolf.cornelissen@gmail.com> updated docs. The driver is now synced against nVidia's official april 2007 ID list.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22687 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 877ed9ed9371d32a919af77b653113f78376c500 Tue Oct 23 13:57:21 MDT 2007 Rudolf Cornelissen <rudolf.cornelissen@gmail.com> updated docs. The driver is now synced against nVidia's official april 2007 ID list.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22687 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/add-ons/kernel/busses/usb/
H A Dehci.cppdiff 877c1b93 Sun Feb 09 15:32:57 MST 2020 Augustin Cavalier <waddlesplash@gmail.com> EHCI: Call InitKernelAccess at the top of SubmitTransfer functions.

I missed that this was not done before WriteDescriptor was called.
Fixes #14835 (again.)
/haiku/src/servers/app/drawing/Painter/
H A DPainter.cppdiff 57e24888 Sun Jan 13 03:04:37 MST 2019 Stephan Aßmus <superstippi@gmx.de> Get rid of special B_OP_COPY implementation for rendering text

Since BeOS had no anti-aliased drawing except for text, it didn't
matter whether drawing diagonal lines (for example) in B_OP_COPY
or B_OP_OVER. Applying the meaning of B_OP_COPY strictly to everything
else would have broken pretty much every existing BeOS, resulting
in broken drawing for anything but straight lines and rectangles.
The solution was to treat B_OP_COPY just like B_OP_OVER *except*
for text rendering, where we could be compatible with the BeOS
behavior. Nevertheless, one can sometimes observe apps using B_OP_COPY
where they /should/ be using B_OP_OVER for rendering text, resulting
in white edges around the glyphs where the actual LowColor() does not
match the current background on which the text is rendered.
There is however a problem when glyphs in a string overlap. Some
fonts have overlapping glyphs by default (handwriting, etc). With
the LCD sub-pixel filtering, this problem is visible even in fonts
where glyphs don't overlap normally, for example 'lt'. The leftmost
pixel of the 't' is smeared due to the filtering and produces an
almost transparent pixel which is rendered (using the low color as
the background) on top of the 'l'. To fix this, one would have to
render the string into an alpha mask buffer first, and then blend it
all at once using B_OP_COPY. This however defeats the point of
B_OP_COPY, which is to be a performance optimization. So instead, I
opted for the solution that is already in place for everything else,
which is to make B_OP_COPY behave like B_OP_OVER. For the case that
this would have produced a difference, i.e. rendering with the solid
high color, one needs to clear the background using the low color,
before rendering text, or it would have looked broken. So in practice,
there cannot be a difference.

Change-Id: I4348902ae754507f1429e0a9575f03d8ecbce333
Reviewed-on: https://review.haiku-os.org/c/877
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

Completed in 465 milliseconds