Surface autofocus

Fri Jul 1 08:00:21 UTC 2016

On Thu, 30 Jun 2016 15:07:29 +0000 (UTC)
Claudiu Lupu <lupuu.claudiu at yahoo.com> wrote:

> Hello,
> I am back with my transparent pixels "click-through" and I really
> want to make weston redirect the touch inputs to a foreground surface
> in case the top one has transparent pixels.pq made me understand more
> on how I should use wl_region but this won't work for me(currently).

Hi,

did you mean to write "background surface"?

> Anyway I am not familiar with weston code but I know I it works so I
> did some "reading" on it and stopped in
> compositor.c/weston_compositor_pick_view... For me this looks like a
> good place to redirect inputs and I thought I can add
> weston_surface_copy_content call for one pixel, check it and send the
> focus to the surface I want.Since I still setting up my wayland
> "build" environment and can't compile/test I thought to get some
> thoughts from you.

That theory is correct. Pick_view is used to determine what
view/surface should get the input targeting the specified coordinates.

> I don't want to achieve great rendering performance and I know that
> even copying 4 bytes from GPU is slow but I do this only when I get
> touch events and I need to stop rendering anyway(stop and render
> something else depending on what the user does with its fingers).

You are talking about stalling the compositor here, not just "rendering
something". That means *everything* will stop, not only rendering.

If it takes too long, you will start dropping input events, the sooner
the faster the input devices produce them.

At least the compositor is not rendering to the same buffer you want to
be reading from, so probably there is no waiting for the previous GPU
rendering to finish - but if the app rendered with GL, then there could
be that too. And that can be a big hit.

Normally when Weston renders, it will just queue more GPU tasks after
app GPU tasks, without waiting for app GPU tasks to finish. Reading
pixel values, even just one pixel, forces to wait for the app GPU task
to finish. This is one very expensive action, actually copying the
pixels to CPU domain is another.

> diff --git a/libweston/compositor.c b/libweston/compositor.cindex
> 37d94ec..268595c 100644--- a/libweston/compositor.c+++
> b/libweston/compositor.c@@ -1702,6 +1702,20 @@
> weston_compositor_pick_view(struct weston_compositor *compositor,
>  view_ix, view_iy, NULL))  continue; + //alpha picking+ unsigned char
> buffer[4]; + if(!weston_surface_copy_content(struct weston_surface
> *surface,+ (void)buffer, 4, view_ix, view_iy, 1, 1)) {+ printf("ALPHA
> %x, B %x, G %x, R %x\n",buffer[0], buffer[1], buffer[2],
> buffer[3]);+ //IGNORE this surface if the pixel has alpha
> 0(transparent)+ if(0 == buffer[0])+ continue;+ }+ else+ {+
> printf("Error reading pixels.\n");+ }+  *vx = view_x;  *vy = view_y;
> return view;

Sorry, I can't read such a mess, but looks like you are calling
weston_surface_copy_content() from inside weston_compositor_pick_view()?

weston_compositor_pick_view() is a fairly hot function, being called
for every pointer and touch motion event usually.

weston_surface_copy_content() OTOH is a very heavy and slow function
intended only for debugging purposes, where performance is irrelevant.
Calling it even only when surface contents have changed would be
awkward. It doesn't matter too much how many pixels you are reading at
a time. It is all the synchronization and setup that makes it heavy.

IOW, you have the right technical solution to inspect alpha, but I
still believe it will not perform well enough to be usable, except
maybe for very specific hardware and software setups.

Thanks,
pq

> 
> Thanks,Claudiu
>       From: Pekka Paalanen <ppaalanen at gmail.com>
>  To: Claudiu Lupu <lupuu.claudiu at yahoo.com> 
> Cc: Wayland Mailing List <wayland-devel at lists.freedesktop.org>
>  Sent: Tuesday, June 21, 2016 4:47 PM
>  Subject: Re: Surface autofocus
>    
> On Tue, 21 Jun 2016 14:23:31 +0000 (UTC)
> Claudiu Lupu <lupuu.claudiu at yahoo.com> wrote:
> 
> > Hello,
> > I got weston 1.11.90 installed on Ubuntu desktop. If I start a
> > terminal window and weston-flower the focus is not being redirected
> > to the terminal in case I click on a transparent zone from flower  
> 
> Hi,
> 
> The transparent parts of the flower are not marked as "click-through"
> by the demo, so this is expected.
> 
> > demo.Another odd thing is that if I click on the terminal window,
> > the terminal gets focus but the flower changes even if I don't
> > click on the flower zone, looks like both surfaces receive mouse
> > down.Same thing happens with the touch. This doesn't look like the
> > behavior I was used to on older version of compositors.  
> 
> The flower does not change as a response to a click per se. The flower
> changes every time the window is redrawn by the demo (this goes to
> show how rarely the window needs redrawing). When window focus
> changes, a message gets sent to both the old and new active windows
> for them to redraw their decorations as active/inactive. Flower does
> not have such decorations, but it redraws anyway.
> 
> You can also see it by pressing Mod+Tab to switch between windows.
> 
> There was a time when flower was redrawn practically never, but that
> has since changed, with the migration to xdg-shell, IIRC.
> 
> > Is this intended, can I
> > change something in weston.ini and enable the "autofocus".
> > Thanks,Claudiu  
> 
> I'm not sure what you mean by "autofocus".
> 
> 
> Thanks,
> pq
> 
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160701/2c271a57/attachment.sig>