[Spice-devel] [PATCH 25/30] Replace custom region implementation with pixman_region32_t

Alexander Larsson alexl at redhat.com
Fri Feb 19 00:58:07 PST 2010


On Fri, 2010-02-19 at 10:40 +0200, Izik Eidus wrote:
> On Thu, 18 Feb 2010 21:58:51 +0100 Alexander Larsson <alexl at redhat.com> wrote:
> 
> red_display_send_upgrade(DisplayChannel *display_channel, UpgradeIte
> >      copy->base.box = qxl_drawable->bbox;
> >      copy->base.clip.type = SPICE_CLIP_TYPE_RECTS;
> >      copy->base.clip.data = channel->send_data.header.size;
> > -    add_buf(channel, BUF_TYPE_RAW, &item->region.num_rects,
> sizeof(uint32_t), 0, 0);
> > -    add_buf(channel, BUF_TYPE_RAW, item->region.rects,
> sizeof(SpiceRect) * item->region.num_rects, 0, 0);
> > +    rects = region_dup_rects(&item->region, &num_rects);
> > +    num_rects32 = num_rects;
> > +    add_buf(channel, BUF_TYPE_RAW, &num_rects32, sizeof(uint32_t),
> 0, 0);
> > +    add_buf(channel, BUF_TYPE_RAW, rects, sizeof(SpiceRect) *
> num_rects, 0, 0);
> > +    free(rects);
> 
> 
> So this is wrong, add_buf() will add the address of what rects is
> pointing to the
> sending vector, but then you free() it before the server send it.
> 
> The way to deal with this would be freeing it at
> red_display_release_stream_clip()
> and allocating the memory at the callers of __new_stream_clip()

Ah, yeah, that sucks. Will fix.

> > +        add_buf(channel, BUF_TYPE_RAW, &num_rects32,
> sizeof(uint32_t), 0, 0);
> > +        add_buf(channel, BUF_TYPE_RAW, rects, num_rects *
> sizeof(SpiceRect), 0, 0);
> > +	free(rects);
> 
> The same problem.

Yeah.

> So about this patch just one more question:
> It look to me like there are some cases we translate rects from one
> type into another
> where we could have use one type in the begining?,
> (I did see many cases that it is a most, But some looked like we could
> avoid this?)

I agree, and it would be trivial to make SpicePoint and pixman_box32_t
identical. There are two differences atm, SpicePoint is packed, and the
coordinates are in another order. If we just changed the order and
removed the packed (which is unlikely to matter anyway in a struct with
4 int32_ts) then we could avoid all the conversions.

However, SpiceRect can't change, since its used as-is in the binary
format of the spice protocol...

Yet another reason we want to have a real demarshaller...


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a notorious Amish romance novelist from the 'hood. She's a high-kicking 
wisecracking barmaid in the wrong place at the wrong time. They fight crime! 



More information about the Spice-devel mailing list