Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

On Friday 2015-11-06 07:16 -0800, Darin Adler wrote: > > On Nov 5, 2015, at 11:24 PM, L. David Baron wrote: > > > > For what it's worth, Gecko does have code to produce a > > minimal-length alpha value. nsStyleUtil::ColorComponentToFloat just > > tries rounding to 2 decimal

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

> On Nov 5, 2015, at 11:24 PM, L. David Baron wrote: > > For what it's worth, Gecko does have code to produce a > minimal-length alpha value. nsStyleUtil::ColorComponentToFloat just > tries rounding to 2 decimal places, sees if the resulting float > round-trips back to the

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

On Monday 2015-11-02 08:37 -0800, Simon Fraser wrote: > > On Nov 1, 2015, at 7:40 PM, Darin Adler wrote: > > > > Hi folks. > > > > Our engine supports alpha values from 0-255. But when we serialize them, we > > turn them into floating point values. When we do that, we include

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

> On Nov 4, 2015, at 1:43 PM, Alfonso Guerra wrote: > > > > On Wed, Nov 4, 2015 at 1:22 PM, Filip Pizlo > wrote: > >> On Nov 4, 2015, at 10:03 AM, Alfonso Guerra > >

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

On Wed, Nov 4, 2015 at 1:22 PM, Filip Pizlo wrote: > > On Nov 4, 2015, at 10:03 AM, Alfonso Guerra > wrote: > > was ~20% faster on my machine. > > > It’s very surprising that this made any difference. Compilers are > ordinarily smart enough to

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

> On Nov 4, 2015, at 10:03 AM, Alfonso Guerra wrote: > > Gavin, > > That's impressive problem-solving and analytical work. > > However, for performance reasons the pre-increment (and pre-decrement) > operators are preferable unless one actually needs to obtain a

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

Gavin, That's impressive problem-solving and analytical work. However, for performance reasons the pre-increment (and pre-decrement) operators are preferable unless one actually needs to obtain a variable's value before updating it. void fasterUnsignedCharToFloatString(unsigned char uc, char*

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

Minimal strings should round trip ok, but will it still be accurate enough if the client attempts to do math with them? It's at least theoretically possible someone may try to multiply by the alpha value. - Maciej > On Nov 2, 2015, at 12:28 AM, Gavin Barraclough

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

> On Nov 3, 2015, at 11:10 AM, Maciej Stachowiak wrote: > > Minimal strings should round trip ok, but will it still be accurate enough if > the client attempts to do math with them? I was thinking about the same thing this morning. If we don’t want them minimal, then how many

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

> On Nov 2, 2015, at 8:37 AM, Simon Fraser wrote: > >> On Nov 1, 2015, at 7:40 PM, Darin Adler wrote: >> >> 1) Does the CSS specification allow or encourage this? > > As long as the values round-trip, I think it’s OK. They absolutely will round-trip.

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

> On Nov 2, 2015, at 8:37 AM, Simon Fraser wrote: > > I would like to know what other browsers do. Someone should check Firefox and IE, I guess. I think it’s likely that Chrome still has the behavior that Blink inherited from WebKit when Google forked it, and someone

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

> On Nov 2, 2015, at 2:34 AM, Gavin Barraclough wrote: > > I guess if you just store the fractions as BCD & unpack you can get the table > size down to 512 bytes. I like that approach. (I’d probably leave leave off the first F from each one and then use 3 instead of 4

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

> On Nov 1, 2015, at 7:40 PM, Darin Adler wrote: > > 3) Can you help me come up with a super-efficient algorithm to do this > serialization? Table lookup? FP conversion code is hard, and this is a relatively small number of strings. You could also flatten all the strings

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

> On Nov 1, 2015, at 7:40 PM, Darin Adler wrote: > > Hi folks. > > Our engine supports alpha values from 0-255. But when we serialize them, we > turn them into floating point values. When we do that, we include way too > many digits of precision. For example, the alpha value

Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

> On Nov 1, 2015, at 7:40 PM, Darin Adler wrote: > > 3) Can you help me come up with a super-efficient algorithm to do this > serialization? Oh – I guess if you just store the fractions as BCD & unpack you can get the table size down to 512 bytes. If you decide against

[webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

Hi folks. Our engine supports alpha values from 0-255. But when we serialize them, we turn them into floating point values. When we do that, we include way too many digits of precision. For example, the alpha value 127 becomes 0.498039. I like the idea of writing the minimum number of digits