On 26.11.2012, at 21:01, Gerd Hoffmann wrote:
> On 11/26/12 19:42, Alexander Graf wrote:
>> Replying here because my INBOX doesn't contain the original message.
>>
+#if PIXMAN_VERSION >= PIXMAN_VERSION_ENCODE(0, 21, 8)
+type = PIXMAN_TYPE_RGBA;
+#endif
+}
On 11/26/12 19:42, Alexander Graf wrote:
> Replying here because my INBOX doesn't contain the original message.
>
>>> +#if PIXMAN_VERSION >= PIXMAN_VERSION_ENCODE(0, 21, 8)
>>> +type = PIXMAN_TYPE_RGBA;
>>> +#endif
>>> +}
>>> +} else if (rshift < gshift && gshift < bshift)
Replying here because my INBOX doesn't contain the original message.
On 18.09.2012, at 21:14, Anthony Liguori wrote:
> Gerd Hoffmann writes:
>
>> Stop reinventing the wheel. Use the pixman library for raster ops.
>>
>> Signed-off-by: Gerd Hoffmann
>
> Why not cairo? I already have a cairo
On Fri, 21 Sep 2012, Gerd Hoffmann wrote:
> On 09/20/12 17:33, Stefano Stabellini wrote:
> > On Thu, 20 Sep 2012, Stefano Stabellini wrote:
> >> On Thu, 20 Sep 2012, Gerd Hoffmann wrote:
> >>> Hi,
> >>>
> > In any graphics mode relevant today vga emulation will use
> > qemu_create_display
On 09/20/12 17:33, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Stefano Stabellini wrote:
>> On Thu, 20 Sep 2012, Gerd Hoffmann wrote:
>>> Hi,
>>>
> In any graphics mode relevant today vga emulation will use
> qemu_create_displaysurface_from(). Whenever a DisplayAllocator is
> pr
On Thu, 20 Sep 2012, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Gerd Hoffmann wrote:
> > Hi,
> >
> > >> In any graphics mode relevant today vga emulation will use
> > >> qemu_create_displaysurface_from(). Whenever a DisplayAllocator is
> > >> present or not doesn't make any difference the
On Thu, 20 Sep 2012, Gerd Hoffmann wrote:
> Hi,
>
> >> In any graphics mode relevant today vga emulation will use
> >> qemu_create_displaysurface_from(). Whenever a DisplayAllocator is
> >> present or not doesn't make any difference then.
> >
> > Unfortunately if my memory doesn't fail me, Win
Hi,
>> In any graphics mode relevant today vga emulation will use
>> qemu_create_displaysurface_from(). Whenever a DisplayAllocator is
>> present or not doesn't make any difference then.
>
> Unfortunately if my memory doesn't fail me, Windows uses 24 bpp.
> So actually the DisplayAllocator int
On Thu, 20 Sep 2012, Gerd Hoffmann wrote:
> Hi,
>
> > It might be a good idea to get rid
> > of DisplayAllocator altogether.
>
> After some digging in the source code: Yes, I think so.
>
> Look, we have *two* concepts for avoiding memcpy:
>
> The first is the DisplayAllocator. Only implemen
Hi,
> It might be a good idea to get rid
> of DisplayAllocator altogether.
After some digging in the source code: Yes, I think so.
Look, we have *two* concepts for avoiding memcpy:
The first is the DisplayAllocator. Only implemented by SDL, which is
scheduled to be downgraded by anthonys gt
On Thu, 20 Sep 2012, Gerd Hoffmann wrote:
> > Pixman or non-pixman, I still think that this could benefit from
> > implementing a DisplayAllocator interface: it would avoid a memcpy
> > whenever there is no need for scaling and pixel conversions.
>
> There is one more issue I didn't mention yet:
Hi,
>> +if (surface) {
>> +pixman_image_unref(surface);
>> }
>> +surface = pixman_from_displaystate(ds);
>
> Am I reading this right? Are you creating a new pixman surface in every
> call to fbdev_update?
No. The whole block doing this is wrapped into "if
On Wed, 19 Sep 2012, Gerd Hoffmann wrote:
> Stop reinventing the wheel, use the pixman library for raster ops.
> Also add setdata callback.
>
> Signed-off-by: Gerd Hoffmann
> ---
> configure | 12
> ui/fbdev.c | 182
> +---
> 2 fi
Stop reinventing the wheel, use the pixman library for raster ops.
Also add setdata callback.
Signed-off-by: Gerd Hoffmann
---
configure | 12
ui/fbdev.c | 182 +---
2 files changed, 124 insertions(+), 70 deletions(-)
diff --git a
On 09/18/12 22:30, Søren Sandmann wrote:
> Gerd Hoffmann writes:
>
>> +static pixman_image_t *pixman_from_displaystate(DisplayState *ds)
>> +{
>> +static pixman_image_t *pixman_from_framebuffer(void)
>> +{
> You may want to call pixman_format_supported_source/destination() here
> to ensure that
On 09/18/12 17:01, Stefano Stabellini wrote:
> On Tue, 18 Sep 2012, Gerd Hoffmann wrote:
>> Stop reinventing the wheel. Use the pixman library for raster ops.
>
> I would separate the pixmap changes from this series: either we use
> this library everywhere or nowhere. At the very least vnc could
Anthony Liguori writes:
> Gerd Hoffmann writes:
>
>> Stop reinventing the wheel. Use the pixman library for raster ops.
>>
>> Signed-off-by: Gerd Hoffmann
>
> Why not cairo? I already have a cairo backend that uses GTK that
> supports scaling. That would be a good opportunity for sharing eve
Gerd Hoffmann writes:
> +static pixman_image_t *pixman_from_displaystate(DisplayState *ds)
> +{
> +PixelFormat *pf = &ds->surface->pf;
> +pixman_format_code_t format;
> +pixman_image_t *image;
> +int type;
> +
> +type = pixman_shifts_to_type(pf->rshift, pf->gshift, pf->bshift)
Gerd Hoffmann writes:
> Stop reinventing the wheel. Use the pixman library for raster ops.
>
> Signed-off-by: Gerd Hoffmann
Why not cairo? I already have a cairo backend that uses GTK that
supports scaling. That would be a good opportunity for sharing even
more code.
Regards,
Anthony Liguo
On Tue, 18 Sep 2012, Gerd Hoffmann wrote:
> Stop reinventing the wheel. Use the pixman library for raster ops.
I would separate the pixmap changes from this series: either we use
this library everywhere or nowhere. At the very least vnc could use it.
Also considering that you only support 32bpp
Stop reinventing the wheel. Use the pixman library for raster ops.
Signed-off-by: Gerd Hoffmann
---
configure | 12
ui/fbdev.c | 172 +++
2 files changed, 114 insertions(+), 70 deletions(-)
diff --git a/configure b/configure
inde
21 matches
Mail list logo
