Dont you mean 2BPP - i.e 16bit ?
== Matthew
On Wed, 2008-07-02 at 14:28 +0800, HASWANI HARISH-VCKR47 wrote:
Hi All,
While going through clutter_texture_set_from_rgb_data API, I found
that currently clutter support only 4 BPP.
will clutter 0.8 support 3BPP ( implies support for
In which case no not yet and doubtful for 0.8.0 at least unless someone
sends a patch.
== Matthew
On Wed, 2008-07-02 at 17:01 +0800, HASWANI HARISH-VCKR47 wrote:
Yes, 2BPP = 2Bytes per pixel like RGBA5551 or RGBA or RGB565
Regards,
Harish Haswani,
LJ-P2P, GRAPHICS, MME Group,
On Wed, 2008-07-02 at 14:28 +0800, HASWANI HARISH-VCKR47 wrote:
While going through clutter_texture_set_from_rgb_data API, I found
that currently clutter support only 4 BPP.
will clutter 0.8 support 3BPP
Clutter happily supports 3 bytes per pixel if by that you mean 1 byte
for each of the
Hi;
On Tue, 2008-07-01 at 20:17 -0400, Jason Tackaberry wrote:
On Tue, 2008-07-01 at 23:27 +0100, Matthew Allum wrote:
I've never noticed high CPU usage with
clutter_texture_set_from_rgb_data(). Have you tried profiling it to
check if it really is set_from_rgb_data and if it is, if
On Wed, 2008-07-02 at 10:13 +0100, Neil Roberts wrote:
On Wed, 2008-07-02 at 14:28 +0800, HASWANI HARISH-VCKR47 wrote:
While going through clutter_texture_set_from_rgb_data API, I found
that currently clutter support only 4 BPP.
will clutter 0.8 support 3BPP
Clutter happily
On Wed, 2008-07-02 at 10:59 +0100, Robert Bragg wrote:
One option is to use cogl_texture_new_from_data which supports more
formats and also lets you control the internal format.
I was just about to reply saying the same thing with this little
example:
cogl_tex = cogl_texture_new_from_data
I've been looking at this and have been coming to the same conclusion.
You could pack the yuv (444, 422, 420, whatever) data in an arbitrary
way into an RGBA texture and use shaders to translate to real RGBA. This
would avoid the multi-texturing, but I imagine you'd still have to munge
the data to
On Wed, 2008-07-02 at 11:21 +0100, Chris Lord wrote:
I've been looking at this and have been coming to the same conclusion.
You could pack the yuv (444, 422, 420, whatever) data in an arbitrary
way into an RGBA texture and use shaders to translate to real RGBA. This
would avoid the
[Resending to list again; sigh, clutter is the only list I use which doesn't
rewrite Reply-To :)]
On Wed, 2008-07-02 at 10:13 +0100, Neil Roberts wrote:
Clutter happily supports 3 bytes per pixel if by that you mean 1 byte
for each of the R, G and B components and no alpha channel. You just
Matthew Allum wrote on 02/07/08 05:14 AM:
Could you try adding 'g_object_set (tex, disable-slicing, TRUE, NULL);
to the test and see if that makes any difference for you.
No change here.
I asked someone to test this on his system using Intel GMA for me, and
he says that the actual time spent
On Wed, 2008-07-02 at 08:28 -0400, Jason Tackaberry wrote:
[Resending to list again; sigh, clutter is the only list I use which doesn't
rewrite Reply-To :)]
Can anyone fix this? I've fallen for that a few times too :(
Is the 3bpp support first converted to 4bpp in software before uploading
James Ketrenos wrote on 02/07/08 01:21 PM:
By setting LIBGL_ALWAYS_INDIRECT=true I am able to run trunk's
tests/pixmap-test TFP code path without a crash, although it doesn't
update the actor with the redirected window contents...
Indeed, that does seem to be the case for my tester as well.
Hi,
Before filing a bug, I thought I'd fly this by others on the list to see
if either I'm doing something wrong, or nobody but me is seeing this
issue.
I'm applying a simple behaviour to a ClutterGLXTexturePixmap and I'm
seeing many skipped frames in the timeline. However, the redirected
On Wed, 2008-07-02 at 21:09 -0400, Jason Tackaberry wrote:
seeing many skipped frames in the timeline. However, the redirected
window is a video, and no frames seem to be dropped on the video itself,
it's just the animation that is choppy. This suggests to me it's not a
bottleneck in the GPU
14 matches
Mail list logo
