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
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
19 matches
Mail list logo
