Hello,
This has already been discussed a while back.
Neither API is good, it really depends on the fb driver. From what I
can tell, the linux driver documentation is very vague about what
these functions actually do.
On some drivers, FBIOPAN_DISPLAY does a *smooth* panning, which is
most
The critical section is usually implemented like this:
#include utils/threads.h
mutable Mutex mLock;
foo()
{
Mutex::Autolock l(mLock);
// critical section here
}
Mathias
On May 20, 8:11 am, Dave Sparks davidspa...@android.com wrote:
I inserted comments below. You need to make sure that
Just an additional note, in case it's not obvious,
all sp needs to work is the incStrong() and decStrong() methods.
Since it's a template, it doesn't require the target object to derive
from RefBase().
In other words, you can use spT as long as T::incStrong() and
T::decStrong() exist and are
Hi,
Assuming you have a GL driver that supports multiple contexts (which
is NOT the case on the G1), you can have several applications using
GLES at the same time; but NOT on the same surface. You cannot bind 2
contexts to the same surface. Now, the framebuffer *is* a surface and
it is used by
Hi,
I'm not completely sure about what you're asking, so I'll do my best
to answer :-)
There is only one thread per process handling the events. Note that
there should only be one instance of SensorManager as well (it's a
singleton).
It's therefore not possible to have more than one thread per
fully opaque turn into partially transparent
pixels (with alpha 254). It is only a very slight difference but it
can be avoided.
On Feb 27, 8:52 am, pixelflinger pixelflin...@google.com wrote:
Hello,
If you compute the errors, that is:
a*float(256/255) - (a + (a7))
and
a*float(256/255
)a == a);
SkASSERT((uint8_t)b == b);
unsigned prod = SkMulS16(a, b) + 128;
return (prod + (prod 8)) 8;
}
This is used in some places for blending. I think it has even smaller
error than (a + (a 7)), though it is slower.
On Feb 27, 6:29 am, pixelflinger pixelflin
Hello,
If you compute the errors, that is:
a*float(256/255) - (a + (a7))
and
a*float(256/255) - (a + 1)
you'll see that the former is a better choice; the maximum error is
smaller (0.5 instead of 1.0)
The later is also incorrect per the OpenGL blending specification
because it doesn't map 0
