From maheshgawali@outlook.com Fri Nov 2 06:41:01 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 28A7375024E for ; Fri, 2 Nov 2012 06:41:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TW_GL=0.077] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcNKfhXjPmb6 for ; Fri, 2 Nov 2012 06:40:58 +0000 (UTC) Received: from snt0-omc2-s43.snt0.hotmail.com (snt0-omc2-s43.snt0.hotmail.com [65.54.61.94]) by menubar.gnome.org (Postfix) with ESMTP id F015C75000A for ; Fri, 2 Nov 2012 06:40:57 +0000 (UTC) Received: from SNT002-W7 ([65.55.90.71]) by snt0-omc2-s43.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Nov 2012 23:40:51 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c121b5e3-f553-4ae5-b6af-3af1ef6b4d4e_" X-Originating-IP: [203.244.218.1] From: mahesh gawali To: "clutter-list@gnome.org" Subject: Clutter Backends - EGL and X11 Date: Fri, 2 Nov 2012 06:40:52 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2012 06:40:51.0948 (UTC) FILETIME=[007702C0:01CDB8C5] X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 06:41:01 -0000 --_c121b5e3-f553-4ae5-b6af-3af1ef6b4d4e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= If I choose backend as (on ARM v7 target) export CLUTTER_BACKEND=3D'eglnative'export CLUTTER_INPUT_BACKEND=3D'null' my simple clutter application(display a rectangle) does not display anythin= g. it does not error out either. FPS is shown as around 60 in the terminal=2C but i do not get anything disp= layed.It works fine when I choose export CLUTTER_BACKEND=3D'x11'export CLUT= TER_INPUT_BACKEND=3D'null' Also I checked on how x11 and eglnative backends are setup in clutter-cogl.= Looks likein file clutter-backend-eglnative.cEGLDisplay clutter_egl_get_eg= l_display (void)is never called during setting up eglnative backend. =0A= = --_c121b5e3-f553-4ae5-b6af-3af1ef6b4d4e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=0A= =0A= =0A=
If I choos= e =3Bbackend =3Bas =3B(on ARM v7 target)

export CLUTTER_BACKEND=3D'eglnative'
export CLUTTER_INPUT_BACKEND= =3D'null'

my simple clutte= r application(display a rectangle) does not display anything. it does not e= rror out either.

FPS is shown as around = 60 in the terminal=2C but i do not get anything displayed.
I= t works fine when I choose =3B
export CLUTTER_BACKEND=3D'x11'
export CLUTTER_INPUT_BACKEND=3D'null'

Also I checked on how x11 and eglnative backends= are setup in clutter-cogl. Looks like
in file =3Bclutter-backend-eglnative.c
EGLDisplay =3B<= span style=3D"font-family: Calibri=2C sans-serif=3B ">clutter_egl_get_egl_d= isplay (void)
is never called during setting up e= glnative backend.



=0A=
= --_c121b5e3-f553-4ae5-b6af-3af1ef6b4d4e_-- From llandwerlin@gmail.com Fri Nov 2 09:44:29 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E01947500E3 for ; Fri, 2 Nov 2012 09:44:28 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TW_GL=0.077] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPToraZbYcFq for ; Fri, 2 Nov 2012 09:44:15 +0000 (UTC) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by menubar.gnome.org (Postfix) with ESMTP id A9900750024 for ; Fri, 2 Nov 2012 09:44:14 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1917504bkc.27 for ; Fri, 02 Nov 2012 02:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=inaDjWXTQBsUf4auWqrBfzSHQGMBJaC6/0hwoA1lC6U=; b=ew89JW6KH8SZ3xj/zXCoj0BKq2QxghmHIju1aXEcSQr8fuJDd3xO6EmSrhHsH0K1my pGc49pehhIytig/jmM4iQIiEZvvYa/CEcRH4IlmK+MULIfHmK9FxpZoVmv7RyFXRVkVM gJws9BxB9wPG31x5l+W6Ns1f+eakjjUAE4whZp5rWoIO8Zt9hg0aWifGJzsrZcsiwI7c ltWera4iuPLnRBT3KW3OE+IBoJtfUxQkGE6pURoowO0fFz4giDIZOz0G+OZW6j0uBdFa 9EOSPe6wAvxo2AFHKI1OnPNR2EHYmzGcgFq7wZfNQqew789bgDM3N6k+ZNi8U/wLFZh6 vwNw== Received: by 10.204.149.10 with SMTP id r10mr219784bkv.61.1351849452334; Fri, 02 Nov 2012 02:44:12 -0700 (PDT) Received: from [192.168.0.3] (b0fb67a4.bb.sky.com. [176.251.103.164]) by mx.google.com with ESMTPS id x13sm6127805bkv.16.2012.11.02.02.44.10 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 02:44:11 -0700 (PDT) Message-ID: <509395F5.10807@gmail.com> Date: Fri, 02 Nov 2012 09:44:21 +0000 From: Lionel Landwerlin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120418 Icedove/11.0 MIME-Version: 1.0 To: clutter-list@gnome.org Subject: Re: Clutter Backends - EGL and X11 References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050104010509050800030603" X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 09:44:29 -0000 This is a multi-part message in MIME format. --------------050104010509050800030603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Depending on your platform, you might need additional code to setup the display -Lionel On 02/11/12 06:40, mahesh gawali wrote: > If I choose backend as (on ARM v7 target) > > export CLUTTER_BACKEND='eglnative' > export CLUTTER_INPUT_BACKEND='null' > > my simple clutter application(display a rectangle) does not display > anything. it does not error out either. > > FPS is shown as around 60 in the terminal, but i do not get anything > displayed. > It works fine when I choose > export CLUTTER_BACKEND='x11' > export CLUTTER_INPUT_BACKEND='null' > > Also I checked on how x11 and eglnative backends are setup in > clutter-cogl. Looks like > in file clutter-backend-eglnative.c > *EGLDisplay clutter_egl_get_egl_display (void)* > is never called during setting up eglnative backend. > > > > > > _______________________________________________ > clutter-list mailing list > clutter-list@gnome.org > https://mail.gnome.org/mailman/listinfo/clutter-list --------------050104010509050800030603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Depending on your platform, you might need additional code to setup the display

-Lionel

On 02/11/12 06:40, mahesh gawali wrote:
If I choose backend as (on ARM v7 target)

export CLUTTER_BACKEND='eglnative'
export CLUTTER_INPUT_BACKEND='null'

my simple clutter application(display a rectangle) does not display anything. it does not error out either.

FPS is shown as around 60 in the terminal, but i do not get anything displayed.
It works fine when I choose 
export CLUTTER_BACKEND='x11'
export CLUTTER_INPUT_BACKEND='null'

Also I checked on how x11 and eglnative backends are setup in clutter-cogl. Looks like
in file clutter-backend-eglnative.c
EGLDisplay clutter_egl_get_egl_display (void)
is never called during setting up eglnative backend.





_______________________________________________
clutter-list mailing list
clutter-list@gnome.org
https://mail.gnome.org/mailman/listinfo/clutter-list

--------------050104010509050800030603-- From pshirkey@boosthardware.com Thu Nov 8 16:33:33 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 914CA75038D for ; Thu, 8 Nov 2012 16:33:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.369] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8+TcFmGctQj for ; Thu, 8 Nov 2012 16:33:20 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id 178B675022B for ; Thu, 8 Nov 2012 16:33:19 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id 20E6440003; Thu, 8 Nov 2012 17:33:15 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Fri, 9 Nov 2012 03:33:15 +1100 (EST) Message-ID: <52065.188.25.63.54.1352392395.squirrel@boosthardware.com> Date: Fri, 9 Nov 2012 03:33:15 +1100 (EST) Subject: [clutter] scrolling From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:33:33 -0000 Hi, What is the best way to handle a scrollable area with clutter-1.10.8? I have a widget that is larger than the available real estate and I would like to be programatically scroll it. Should I draw the widget once and move it around inside a container hiding the area that is outside of the container boundaries or should I redraw the entire widget for every scroll event? -- Patrick Shirkey Boost Hardware Ltd From ebassi@gmail.com Thu Nov 8 16:42:09 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C49FA7500E5 for ; Thu, 8 Nov 2012 16:42:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdzoIyWdtca9 for ; Thu, 8 Nov 2012 16:41:52 +0000 (UTC) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by menubar.gnome.org (Postfix) with ESMTP id A42C175022B for ; Thu, 8 Nov 2012 16:41:52 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so5120758obb.27 for ; Thu, 08 Nov 2012 08:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WTIMP8x7qi4rc5zZNmEXoNNzpz16G6PbR4IMvSRF0M4=; b=AmgE+F7SAFlq5Og7ADNhDivyM1hXS2rjI2z+bg6sr8ZBbVfMN3oVk+k9NUM65aAAYB s4QuS//zZyJAl3W8K1eiWFpNy9tALtlmovClJrAjj+OCgGBso8ESkb/av/8YdXx+beUY BGAy6y5vAVCkqfYWcvJDZ233GdjIc/QvZaOrb9W/8b1fTIKg+WWssC1GFIpKDa5XiVuT htDv6cIivNTlhPUflH8wQ6uE3Tl9FAfrvcvPm3o3P/Eu0NMNd13GFI2tjkuoI3D2KfBM Z6iQxh2N4MNcEduc05r331Oomhuql8Qf35qIooWEC9/2q9k91YsSGrYZAJGcsbPc8koD M2iQ== MIME-Version: 1.0 Received: by 10.60.170.9 with SMTP id ai9mr5261922oec.36.1352392910935; Thu, 08 Nov 2012 08:41:50 -0800 (PST) Received: by 10.76.28.10 with HTTP; Thu, 8 Nov 2012 08:41:50 -0800 (PST) In-Reply-To: <52065.188.25.63.54.1352392395.squirrel@boosthardware.com> References: <52065.188.25.63.54.1352392395.squirrel@boosthardware.com> Date: Thu, 8 Nov 2012 16:41:50 +0000 Message-ID: Subject: Re: [clutter] scrolling From: Emmanuele Bassi To: Patrick Shirkey Content-Type: text/plain; charset=UTF-8 Cc: clutter-list@gnome.org X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:42:10 -0000 hi; On 8 November 2012 16:33, Patrick Shirkey wrote: > What is the best way to handle a scrollable area with clutter-1.10.8? > > I have a widget that is larger than the available real estate and I would > like to be programatically scroll it. > > Should I draw the widget once and move it around inside a container hiding > the area that is outside of the container boundaries or should I redraw > the entire widget for every scroll event? you can do a translation inside apply_transform() in the parent of the widget, and clip it. you can have a look at how ClutterScrollActor works in Clutter 1.12; the actor is pretty much self-contained, so you can even reuse its code, if the license allows it. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ From pshirkey@boosthardware.com Thu Nov 8 17:43:19 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 76F6A75022B for ; Thu, 8 Nov 2012 17:43:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.369] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DEqCO3Gi7jC for ; Thu, 8 Nov 2012 17:43:04 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id 8405075000A for ; Thu, 8 Nov 2012 17:43:04 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id 368BF40003; Thu, 8 Nov 2012 18:42:59 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Fri, 9 Nov 2012 04:42:59 +1100 (EST) Message-ID: <52728.188.25.63.54.1352396579.squirrel@boosthardware.com> In-Reply-To: References: <52065.188.25.63.54.1352392395.squirrel@boosthardware.com> Date: Fri, 9 Nov 2012 04:42:59 +1100 (EST) Subject: Re: [clutter] scrolling From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:43:19 -0000 On Fri, November 9, 2012 3:41 am, Emmanuele Bassi wrote: > hi; > > On 8 November 2012 16:33, Patrick Shirkey > wrote: > >> What is the best way to handle a scrollable area with clutter-1.10.8? >> >> I have a widget that is larger than the available real estate and I >> would >> like to be programatically scroll it. >> >> Should I draw the widget once and move it around inside a container >> hiding >> the area that is outside of the container boundaries or should I redraw >> the entire widget for every scroll event? > > you can do a translation inside apply_transform() in the parent of the > widget, and clip it. > At the moment I am drawing all the actors within a single stage. I'm not sure how to move the stage around with a transform. > you can have a look at how ClutterScrollActor works in Clutter 1.12; > the actor is pretty much self-contained, so you can even reuse its > code, if the license allows it. > I will try upgrading to exp as it has 1.12.0 available and that is probably a better use of my time than reinventing the scrollActor. Should I place the actors inside the scrollActor? Do you have a python3 example of using the scrollActor as a parent container with (multiple) child actors inside the container? -- Patrick Shirkey Boost Hardware Ltd From brduffy@gmail.com Fri Nov 9 02:14:38 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D579D750277 for ; Fri, 9 Nov 2012 02:14:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH-FMHImyNmP for ; Fri, 9 Nov 2012 02:14:25 +0000 (UTC) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by menubar.gnome.org (Postfix) with ESMTP id E5F3B75001A for ; Fri, 9 Nov 2012 02:14:24 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so1846243dad.27 for ; Thu, 08 Nov 2012 18:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cc1O91kkPdFQvfRlkABY78v8o2S9gZZO/qNsS3ts3+U=; b=noHW/+rKUelTcyQ2fKsJvjxKmhs6+jLLki0MmXSA3qva3UnT2iyasu7ZFON1Oz8g6t KtoKYor1ZSzKYCI8hNnKKM4JJjPDG+Djws24rQV0tkJqqZzTyNNolp+qKaU7vs6TTT2s 4Rx5nraQVevkzuXAeAhZxywx78gg3PTIEnGamKxbRo/yQsHfoOG0MWDj40aM2cYczG/h KE4RjdjCYrWIXeqvuPwKjHByQ3GHrh0u7QOT1t4I0+w2vxfO6ttxttiw9TWyA3X6XRRL 7uCMQOMG3sZ9e1VaFQs0afsxHB11lG9tE0MF8dPJ6YEqLtGGBsGGIuzlGDH1A94cSyEM xqow== MIME-Version: 1.0 Received: by 10.66.80.133 with SMTP id r5mr27750299pax.24.1352427263186; Thu, 08 Nov 2012 18:14:23 -0800 (PST) Received: by 10.66.222.132 with HTTP; Thu, 8 Nov 2012 18:14:23 -0800 (PST) In-Reply-To: <52728.188.25.63.54.1352396579.squirrel@boosthardware.com> References: <52065.188.25.63.54.1352392395.squirrel@boosthardware.com> <52728.188.25.63.54.1352396579.squirrel@boosthardware.com> Date: Thu, 8 Nov 2012 21:14:23 -0500 Message-ID: Subject: Re: [clutter] scrolling From: Brian Duffy To: Patrick Shirkey Content-Type: multipart/alternative; boundary=f46d042ef6719b57ba04ce06824a Cc: clutter-list@gnome.org X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 02:14:39 -0000 --f46d042ef6719b57ba04ce06824a Content-Type: text/plain; charset=ISO-8859-1 uuuggghhh! I wish Fedora 18 would get here soon. I need me some Clutter 1.12 On Thu, Nov 8, 2012 at 12:42 PM, Patrick Shirkey wrote: > > On Fri, November 9, 2012 3:41 am, Emmanuele Bassi wrote: > > hi; > > > > On 8 November 2012 16:33, Patrick Shirkey > > wrote: > > > >> What is the best way to handle a scrollable area with clutter-1.10.8? > >> > >> I have a widget that is larger than the available real estate and I > >> would > >> like to be programatically scroll it. > >> > >> Should I draw the widget once and move it around inside a container > >> hiding > >> the area that is outside of the container boundaries or should I redraw > >> the entire widget for every scroll event? > > > > you can do a translation inside apply_transform() in the parent of the > > widget, and clip it. > > > > At the moment I am drawing all the actors within a single stage. I'm not > sure how to move the stage around with a transform. > > > you can have a look at how ClutterScrollActor works in Clutter 1.12; > > the actor is pretty much self-contained, so you can even reuse its > > code, if the license allows it. > > > > I will try upgrading to exp as it has 1.12.0 available and that is > probably a better use of my time than reinventing the scrollActor. Should > I place the actors inside the scrollActor? > > Do you have a python3 example of using the scrollActor as a parent > container with (multiple) child actors inside the container? > > > > -- > Patrick Shirkey > Boost Hardware Ltd > _______________________________________________ > clutter-list mailing list > clutter-list@gnome.org > https://mail.gnome.org/mailman/listinfo/clutter-list > -- Duff --f46d042ef6719b57ba04ce06824a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable uuuggghhh! I wish Fedora 18 would get here soon. I need me some Clutter 1.1= 2


On Thu, Nov = 8, 2012 at 12:42 PM, Patrick Shirkey <pshirkey@boosthardware.com<= /a>> wrote:

On Fri, November 9, 2012 3:41 am, Emmanuele Bassi wrote:
> hi;
>
> On 8 November 2012 16:33, Patrick Shirkey <
pshirkey@boosthardware.com>
> wrote:
>
>> What is the best way to handle a scrollable area with clutter-1.10= .8?
>>
>> I have a widget that is larger than the available real estate and = I
>> would
>> like to be programatically scroll it.
>>
>> Should I draw the widget once and move it around inside a containe= r
>> hiding
>> the area that is outside of the container boundaries or should I r= edraw
>> the entire widget for every scroll event?
>
> you can do a translation inside apply_transform() in the parent of the=
> widget, and clip it.
>

At the moment I am drawing all the actors within a single stage. I= 9;m not
sure how to move the stage around with a transform.

> you can have a look at how ClutterScrollActor works in Clutter 1.12; > the actor is pretty much self-contained, so you can even reuse its
> code, if the license allows it.
>

I will try upgrading to exp as it has 1.12.0 available and that is probably a better use of my time than reinventing the scrollActor. Should I place the actors inside the scrollActor?

Do you have a python3 example of using the scrollActor as a parent
container with (multiple) child actors inside the container?



--
Patrick Shirkey
Boost Hardware Ltd
_____________________________= __________________
clutter-list mailing list
clutter-list@gnome.org
https://mail.gnome.org/mailman/listinfo/clutter-list



--
= Duff
--f46d042ef6719b57ba04ce06824a-- From pshirkey@boosthardware.com Fri Nov 9 12:08:33 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9A73B751053 for ; Fri, 9 Nov 2012 12:08:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.369] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzJ-0V1GzSWL for ; Fri, 9 Nov 2012 12:08:27 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id 0D67D7504F5 for ; Fri, 9 Nov 2012 12:08:26 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id 9EE4640003; Fri, 9 Nov 2012 13:08:22 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Fri, 9 Nov 2012 23:08:22 +1100 (EST) Message-ID: <42219.188.25.63.54.1352462902.squirrel@boosthardware.com> In-Reply-To: References: <52065.188.25.63.54.1352392395.squirrel@boosthardware.com> <52728.188.25.63.54.1352396579.squirrel@boosthardware.com> Date: Fri, 9 Nov 2012 23:08:22 +1100 (EST) Subject: Re: [clutter] scrolling From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:08:33 -0000 On Thu, Nov 8, 2012 at 12:42 PM, Patrick Shirkey > > Do you have a python3 example of using the scrollActor as a parent > container with (multiple) child actors inside the container? > This code which is working for me except for set_scroll_mode(). Not sure what the python syntax is for the ClutterScrollMode variable. point = Clutter.Point() scrollActor = Clutter.ScrollActor() scrollActor.set_size(1200,768) scrollActor.set_scroll_mode(Clutter.SCROLL_HORIZONTALLY) stage.add_actor(scrollActor) point.x +=50 scrollActor.scroll_to_point(point) -- Patrick Shirkey Boost Hardware Ltd From ebassi@gmail.com Fri Nov 9 16:34:12 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 06D52750214 for ; Fri, 9 Nov 2012 16:34:12 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXpvqvWCuLXr for ; Fri, 9 Nov 2012 16:34:10 +0000 (UTC) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by menubar.gnome.org (Postfix) with ESMTP id 09C3A750102 for ; Fri, 9 Nov 2012 16:34:09 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so7083503obb.27 for ; Fri, 09 Nov 2012 08:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9M703T/PDLXcM63lx7q7dcNNtj6oQy8pdbvPB0etaVI=; b=zNcW40SUQDGI7zmMJgWWDerWgQOMvhfRuqdbWkRvsWsOGd7BskDtuyv6YYQ9IV6FjY e5azGRxbyqsA5zZqkQryCj365KVjvC82nXGnrYD0WoisvFBDbJ0hR4XoZ2CqgJQE/13j cPiXKPgQMHtfK7kFXUWGnnZ4nzDNumtaY95P0zXN5okDAuX/1ZF9h1PlT+/dxrOG9a2m LP028Ssev3+BjdhYnnZRuC4STU8Eu6/dbaTE1l3kjjhirNzffgdx3tfupzBjEYS5ETNt TO+yo/b/03Zbem378xfOu57PlDUz5m9RFa6o2t6V5N6N4HC/4jBvSx1vxFVA0MDvUvuA jesg== MIME-Version: 1.0 Received: by 10.182.108.69 with SMTP id hi5mr9198804obb.43.1352478848397; Fri, 09 Nov 2012 08:34:08 -0800 (PST) Received: by 10.76.28.10 with HTTP; Fri, 9 Nov 2012 08:34:08 -0800 (PST) In-Reply-To: <42219.188.25.63.54.1352462902.squirrel@boosthardware.com> References: <52065.188.25.63.54.1352392395.squirrel@boosthardware.com> <52728.188.25.63.54.1352396579.squirrel@boosthardware.com> <42219.188.25.63.54.1352462902.squirrel@boosthardware.com> Date: Fri, 9 Nov 2012 16:34:08 +0000 Message-ID: Subject: Re: [clutter] scrolling From: Emmanuele Bassi To: Patrick Shirkey Content-Type: text/plain; charset=UTF-8 Cc: clutter-list@gnome.org X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:34:12 -0000 hi; On 9 November 2012 12:08, Patrick Shirkey wrote: > On Thu, Nov 8, 2012 at 12:42 PM, Patrick Shirkey >> >> Do you have a python3 example of using the scrollActor as a parent >> container with (multiple) child actors inside the container? >> > > This code which is working for me except for set_scroll_mode(). Not sure > what the python syntax is for the ClutterScrollMode variable. > > point = Clutter.Point() > > scrollActor = Clutter.ScrollActor() > scrollActor.set_size(1200,768) > scrollActor.set_scroll_mode(Clutter.SCROLL_HORIZONTALLY) scrollActor.set_scroll_mode(Clutter.ScrollMode.HORIZONTALLY) > stage.add_actor(scrollActor) > > point.x +=50 > scrollActor.scroll_to_point(point) hope this helps. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ From pshirkey@boosthardware.com Tue Nov 13 14:17:44 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 95F0475077C for ; Tue, 13 Nov 2012 14:17:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.23] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVdSka-hv86P for ; Tue, 13 Nov 2012 14:17:39 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id B43827503B2 for ; Tue, 13 Nov 2012 14:17:39 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id C73E240003; Tue, 13 Nov 2012 15:17:33 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Wed, 14 Nov 2012 01:17:33 +1100 (EST) Message-ID: <42970.188.25.63.54.1352816253.squirrel@boosthardware.com> Date: Wed, 14 Nov 2012 01:17:33 +1100 (EST) Subject: [clutter] GtkClutter button-press-event segfault From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 14:17:44 -0000 Hi, I get a segfault with 'button-press-event' while using GtkClutter.embed() which I don't get with the exact same class while using Clutter directly without Gtk. Has anyone come across this before or should I do some more advanced debugging? -- Patrick Shirkey Boost Hardware Ltd From pshirkey@boosthardware.com Wed Nov 14 09:41:51 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DAB7075006E for ; Wed, 14 Nov 2012 09:41:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.188] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkC5Tfx5-Vj6 for ; Wed, 14 Nov 2012 09:41:37 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id BDD60750C75 for ; Wed, 14 Nov 2012 09:40:45 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id 1780540003; Wed, 14 Nov 2012 10:40:41 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Wed, 14 Nov 2012 20:40:40 +1100 (EST) Message-ID: <43411.188.25.63.54.1352886040.squirrel@boosthardware.com> In-Reply-To: <42970.188.25.63.54.1352816253.squirrel@boosthardware.com> References: <42970.188.25.63.54.1352816253.squirrel@boosthardware.com> Date: Wed, 14 Nov 2012 20:40:40 +1100 (EST) Subject: Re: [clutter] GtkClutter button-press-event segfault From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:41:51 -0000 On Wed, November 14, 2012 1:17 am, Patrick Shirkey wrote: > Hi, > > I get a segfault with 'button-press-event' while using GtkClutter.embed() > which I don't get with the exact same class while using Clutter directly > without Gtk. > > Has anyone come across this before or should I do some more advanced > debugging? > Please disregard. Turns out the segfault was not from clutter. -- Patrick Shirkey Boost Hardware Ltd From pshirkey@boosthardware.com Wed Nov 14 09:51:55 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C378F750171 for ; Wed, 14 Nov 2012 09:51:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.188] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ7zvOJzRn28 for ; Wed, 14 Nov 2012 09:51:51 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id 6A98A75009C for ; Wed, 14 Nov 2012 09:51:51 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id 1736840003; Wed, 14 Nov 2012 10:51:47 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Wed, 14 Nov 2012 20:51:47 +1100 (EST) Message-ID: <43426.188.25.63.54.1352886707.squirrel@boosthardware.com> Date: Wed, 14 Nov 2012 20:51:47 +1100 (EST) Subject: [clutter] grid with multiple actors From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:51:56 -0000 Hi, I have a grid similar to a spread sheet with multiple actors (approx 1500) which receiving button-press events. 12 rows x 130 columns When the grid is built it takes about 5 seconds to be displayed on screen. The grid can be expanded upto 130,000 actors or approx 1000 rows x 130 columns so it would take approx 500 seconds to build and display in that case. Is there are more efficient method to build a clickable/editable grid with clutter? -- Patrick Shirkey Boost Hardware Ltd From pshirkey@boosthardware.com Wed Nov 14 09:56:54 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C2C8B75009C for ; Wed, 14 Nov 2012 09:56:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.188] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKtZorMN0O9r for ; Wed, 14 Nov 2012 09:56:41 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id EBD6D75006E for ; Wed, 14 Nov 2012 09:56:40 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id A2B3940003; Wed, 14 Nov 2012 10:56:36 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Wed, 14 Nov 2012 20:56:36 +1100 (EST) Message-ID: <43430.188.25.63.54.1352886996.squirrel@boosthardware.com> Date: Wed, 14 Nov 2012 20:56:36 +1100 (EST) Subject: [clutter] color change delay From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:56:55 -0000 Hi, I am seeing a delay of upto 4 seconds to change the color of an actor on button-press-event. Does anyone have a suggestion to make the response time faster? Print statements in the event handler function are immediately written to console so the delay seems to be deeper in the event handling stack. -- Patrick Shirkey Boost Hardware Ltd From llandwerlin@gmail.com Wed Nov 14 10:16:57 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 73C92750268 for ; Wed, 14 Nov 2012 10:16:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWHJIcY3zzY0 for ; Wed, 14 Nov 2012 10:16:39 +0000 (UTC) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by menubar.gnome.org (Postfix) with ESMTP id 4649D750315 for ; Wed, 14 Nov 2012 10:16:38 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so451147lbb.27 for ; Wed, 14 Nov 2012 02:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KTRT2vN9B8tvXLyt54UAkXgH8tDhLa6y0SHK0k2Dptc=; b=skE4bpzW13q4RsbcW15wm5/r83SpgBthBzXTGS4ME1CmRFOIMCOsmFHHNKu7FhQ1J7 8bTUD8UfZp/Kxtj2YwSXBgptcvANaKkldknpJdrzcCAkhy7nZDdZ3pM+XlYWmXSWqe6C nMcwerSb4824mobeuf3FWrbfN0aKDvYK1FNLPMIPzPEj3oiqU3Uo457iYGpOKGwILAJ9 TcMlDQZoTuAPj6NkkYlPGREVhMtF/ZLFys43x+9sMF4i5jz5vAe3qcY7L4AOVFRWyntx n1N0AHl+XnOYtBUqFRsSqvVMKM2brRJ8AIMOkCJdgSmtEaM2/UpkxcSq3sQ+M+KhvrVB Drqw== Received: by 10.112.83.196 with SMTP id s4mr10268500lby.29.1352888196848; Wed, 14 Nov 2012 02:16:36 -0800 (PST) Received: from [192.168.7.171] ([83.217.123.106]) by mx.google.com with ESMTPS id ly18sm475106lab.15.2012.11.14.02.16.34 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 02:16:35 -0800 (PST) Message-ID: <50A36F83.4090100@gmail.com> Date: Wed, 14 Nov 2012 10:16:35 +0000 From: Lionel Landwerlin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121031 Icedove/16.0.2 MIME-Version: 1.0 To: clutter-list@gnome.org Subject: Re: [clutter] grid with multiple actors References: <43426.188.25.63.54.1352886707.squirrel@boosthardware.com> In-Reply-To: <43426.188.25.63.54.1352886707.squirrel@boosthardware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 10:16:57 -0000 On 14/11/12 09:51, Patrick Shirkey wrote: > Hi, > > I have a grid similar to a spread sheet with multiple actors (approx 1500) > which receiving button-press events. 12 rows x 130 columns > > When the grid is built it takes about 5 seconds to be displayed on screen. > > The grid can be expanded upto 130,000 actors or approx 1000 rows x 130 > columns so it would take approx 500 seconds to build and display in that > case. > > Is there are more efficient method to build a clickable/editable grid with > clutter? > > Don't use that many actors. It's a well known weakness of Clutter. -Lionel From pshirkey@boosthardware.com Wed Nov 14 10:48:32 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0A2FC750374 for ; Wed, 14 Nov 2012 10:48:32 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.188] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Sj5C38LcvuM for ; Wed, 14 Nov 2012 10:48:15 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id BD880750C6D for ; Wed, 14 Nov 2012 10:47:27 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id 59F3940003; Wed, 14 Nov 2012 11:47:23 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Wed, 14 Nov 2012 21:47:23 +1100 (EST) Message-ID: <53979.188.25.63.54.1352890043.squirrel@boosthardware.com> In-Reply-To: <50A36F83.4090100@gmail.com> References: <43426.188.25.63.54.1352886707.squirrel@boosthardware.com> <50A36F83.4090100@gmail.com> Date: Wed, 14 Nov 2012 21:47:23 +1100 (EST) Subject: Re: [clutter] grid with multiple actors From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 10:48:32 -0000 On Wed, November 14, 2012 9:16 pm, Lionel Landwerlin wrote: > On 14/11/12 09:51, Patrick Shirkey wrote: >> Hi, >> >> I have a grid similar to a spread sheet with multiple actors (approx >> 1500) >> which receiving button-press events. 12 rows x 130 columns >> >> When the grid is built it takes about 5 seconds to be displayed on >> screen. >> >> The grid can be expanded upto 130,000 actors or approx 1000 rows x 130 >> columns so it would take approx 500 seconds to build and display in that >> case. >> >> Is there are more efficient method to build a clickable/editable grid >> with >> clutter? >> >> > > Don't use that many actors. It's a well known weakness of Clutter. > So instead of having multiple actors as buttons what is the correct method for drawing multiple buttons in the case of a grid? Is there an example somewhere of a clutter grid layout? -- Patrick Shirkey Boost Hardware Ltd From llandwerlin@gmail.com Wed Nov 14 10:53:28 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 803EB750403 for ; Wed, 14 Nov 2012 10:53:28 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfMUiCUOrW7V for ; Wed, 14 Nov 2012 10:53:23 +0000 (UTC) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by menubar.gnome.org (Postfix) with ESMTP id AB795750224 for ; Wed, 14 Nov 2012 10:53:23 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so366777pbc.27 for ; Wed, 14 Nov 2012 02:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=65ElBu42HcjMENCe+jbjq6DnU5mBuv4Atf7ddnw+fhE=; b=xOvGDXG/zuQDM/wHBCKGsZcmhna/2DcYv+zylX4Fl3Ea8xZwa7rFeD8mnKa+6Bqsce tXUrcb4aRvEOC7zpinBht7Q4iiJmlDv0CQeWUa4ZaPt81iUA8wZU31zkwZIkau8U8EEF 0itEJt6XXPKtfWBuXDxka8Pm+XEOXlBZXQv8usAB654Cb1fV5CP81jwjT25JxJH4I+ao Ay63pU4uO46ZzsLK3OrcjlHAsrgzt1y5/zbG2bhwi1IkyhUZfxqgiA0SBZbyBqGowA5t iSjTqBny6ttgwRN7E3y26avC45V64LFJsfa/o504dP6Dp+asX2vn/m8OLLfBdjC/JK0Y h2Fg== Received: by 10.68.197.101 with SMTP id it5mr78035613pbc.91.1352890402063; Wed, 14 Nov 2012 02:53:22 -0800 (PST) Received: from [192.168.7.171] ([83.217.123.106]) by mx.google.com with ESMTPS id k9sm7742738paz.22.2012.11.14.02.53.20 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 02:53:21 -0800 (PST) Message-ID: <50A37821.2010803@gmail.com> Date: Wed, 14 Nov 2012 10:53:21 +0000 From: Lionel Landwerlin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121031 Icedove/16.0.2 MIME-Version: 1.0 To: clutter-list@gnome.org Subject: Re: [clutter] grid with multiple actors References: <43426.188.25.63.54.1352886707.squirrel@boosthardware.com> <50A36F83.4090100@gmail.com> <53979.188.25.63.54.1352890043.squirrel@boosthardware.com> In-Reply-To: <53979.188.25.63.54.1352890043.squirrel@boosthardware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 10:53:28 -0000 On 14/11/12 10:47, Patrick Shirkey wrote: > On Wed, November 14, 2012 9:16 pm, Lionel Landwerlin wrote: >> On 14/11/12 09:51, Patrick Shirkey wrote: >>> Hi, >>> >>> I have a grid similar to a spread sheet with multiple actors (approx >>> 1500) >>> which receiving button-press events. 12 rows x 130 columns >>> >>> When the grid is built it takes about 5 seconds to be displayed on >>> screen. >>> >>> The grid can be expanded upto 130,000 actors or approx 1000 rows x 130 >>> columns so it would take approx 500 seconds to build and display in that >>> case. >>> >>> Is there are more efficient method to build a clickable/editable grid >>> with >>> clutter? >>> >>> >> Don't use that many actors. It's a well known weakness of Clutter. >> > > So instead of having multiple actors as buttons what is the correct method > for drawing multiple buttons in the case of a grid? > > Is there an example somewhere of a clutter grid layout? > > > Am I wrong to think that your display is probably not big enough to display 130 columns? If that's the case, then you probably want to implement a container that reuses actors from a pool just deal with the number of visible items. -Lionel From pshirkey@boosthardware.com Wed Nov 14 11:18:40 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 69809750374 for ; Wed, 14 Nov 2012 11:18:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.188] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vjPcrJ11+AR for ; Wed, 14 Nov 2012 11:18:34 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id 1A2BE750315 for ; Wed, 14 Nov 2012 11:18:33 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id 14EDF40003; Wed, 14 Nov 2012 12:18:27 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Wed, 14 Nov 2012 22:18:27 +1100 (EST) Message-ID: <54188.188.25.63.54.1352891907.squirrel@boosthardware.com> In-Reply-To: <50A37821.2010803@gmail.com> References: <43426.188.25.63.54.1352886707.squirrel@boosthardware.com> <50A36F83.4090100@gmail.com> <53979.188.25.63.54.1352890043.squirrel@boosthardware.com> <50A37821.2010803@gmail.com> Date: Wed, 14 Nov 2012 22:18:27 +1100 (EST) Subject: Re: [clutter] grid with multiple actors From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 11:18:40 -0000 On Wed, November 14, 2012 9:53 pm, Lionel Landwerlin wrote: > On 14/11/12 10:47, Patrick Shirkey wrote: >> On Wed, November 14, 2012 9:16 pm, Lionel Landwerlin wrote: >>> On 14/11/12 09:51, Patrick Shirkey wrote: >>>> Hi, >>>> >>>> I have a grid similar to a spread sheet with multiple actors (approx >>>> 1500) >>>> which receiving button-press events. 12 rows x 130 columns >>>> >>>> When the grid is built it takes about 5 seconds to be displayed on >>>> screen. >>>> >>>> The grid can be expanded upto 130,000 actors or approx 1000 rows x 130 >>>> columns so it would take approx 500 seconds to build and display in >>>> that >>>> case. >>>> >>>> Is there are more efficient method to build a clickable/editable grid >>>> with >>>> clutter? >>>> >>>> >>> Don't use that many actors. It's a well known weakness of Clutter. >>> >> >> So instead of having multiple actors as buttons what is the correct >> method >> for drawing multiple buttons in the case of a grid? >> >> Is there an example somewhere of a clutter grid layout? >> >> >> > > Am I wrong to think that your display is probably not big enough to > display 130 columns? > If that's the case, then you probably want to implement a container that > reuses actors from > a pool just deal with the number of visible items. > I am displaying the following layout keyboard 78 x actors (clickable) - 22 x 100 px 68 x actors (clickable) - 12 x 50 px grid 13 x 131 actors (not clickable) - 1 px 12 x 130 actors (clickable) - 10 x 10 px I can redo the grid so there are only 12x130 actors by combining the two layers but I still need to have approx 1500 visible and clickable buttons on screen at one time. -- Patrick Shirkey Boost Hardware Ltd From brduffy@gmail.com Wed Nov 14 20:58:59 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9867A750576; Wed, 14 Nov 2012 20:58:59 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2f3HjorTw5K; Wed, 14 Nov 2012 20:58:45 +0000 (UTC) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by menubar.gnome.org (Postfix) with ESMTP id 4950C750573; Wed, 14 Nov 2012 20:58:44 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so837727pbc.27 for ; Wed, 14 Nov 2012 12:58:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=h1tJOMVfFWXA2rr1fiLLAtLYbN0g6JV1QCC/h+qdc3s=; b=Jwmy/THFW84BQNmEckixKTyofnBeHKINmVZsxOlc7zYOvD8DzSXy9oCXGD/MYLIumC eM5K2pMmoJIfHtFKDqov2ebTu9y93AeqhnIBE72C1Aj65FIYxWR+CpZ/CW3YC7TPEzDe dzwBsfjaC8sn5QAelLvJaLavsTXLPVm5s9ycenXBlbP0qtVzyDx8aZX9GaVNyHCJ5Z5N wzMzGIwb0FOh6RHKUJJjCqXzFsugOoJuFtGlG+BVUlYs0AQPK5N45pc+H7ih9iiEzy5l OrM5BRx5Uta5QYj9a4+DEttvI/GCVuvHs+jNzpPy64f9kLyDIH5XYoAmqahKFWjwcQpd y8Xg== MIME-Version: 1.0 Received: by 10.66.78.97 with SMTP id a1mr10590449pax.32.1352926723391; Wed, 14 Nov 2012 12:58:43 -0800 (PST) Received: by 10.66.222.132 with HTTP; Wed, 14 Nov 2012 12:58:43 -0800 (PST) Date: Wed, 14 Nov 2012 15:58:43 -0500 Message-ID: Subject: distro for Clutter 1.12? From: Brian Duffy To: clutter-list@gnome.org, "gnome-love@gnome.org" Content-Type: multipart/alternative; boundary=f46d042de7f1c13f3a04ce7accaa X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 20:58:59 -0000 --f46d042de7f1c13f3a04ce7accaa Content-Type: text/plain; charset=ISO-8859-1 After reading some of the mailing list threads for Fedora 18 development, I am wondering if there is another distribution that is recently released (or soon to be) that includes Clutter 1.12? Personally, I don't like trying to maintain my own cutting edge dev environment. I depend on the distro to have the latest available packages for Clutter, Vala, etc. Normally, I would just wait for Fedora, but those Anaconda discussions have me spooked. Any suggestions? thnx Brian -- Duff --f46d042de7f1c13f3a04ce7accaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After reading some of the mailing list threads for Fedora 18 development, I= am wondering if there is another distribution that is recently released (o= r soon to be) that includes Clutter 1.12?=A0

Personally,= I don't like trying to maintain my own cutting edge dev environment. I= depend on the distro to have the latest available packages for Clutter, Va= la, etc. Normally, I would just wait for Fedora, but those Anaconda discuss= ions have me spooked.=A0

Any suggestions?

thnx

Brian

--
Duff
--f46d042de7f1c13f3a04ce7accaa-- From llandwerlin@gmail.com Wed Nov 14 21:01:40 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DBCB77505AC for ; Wed, 14 Nov 2012 21:01:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TW_HN=0.077] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+ArdpBOpbWS for ; Wed, 14 Nov 2012 21:01:35 +0000 (UTC) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by menubar.gnome.org (Postfix) with ESMTP id 69417750573 for ; Wed, 14 Nov 2012 21:01:34 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jm19so573104bkc.27 for ; Wed, 14 Nov 2012 13:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=Gq7GtZocJHBJGNKMar11iTqP3ayC5CsCVvz+eXk0EmI=; b=GJMvLPQwj0QYXlbou6G2hbp8B+mZlq8Q+Gea0tnJnxLfZN+9J1z+DBJZI3Z1jkVTck mWRH4aVds1S1+NKgtTnTTYrDQdylPNrowO1AiTmjoCc0Z/tCGH5DE9N+i53WygH3yfUz mQcYc6zHmSzNGeT61JopWGTmrfw9mFKp/lo+iERn/U8ve6PCFXX3OvLevqdF4UDTE0/f gY/FeiJwftU6DDrhACtygN/n+utDq+/ARhLAU6/CaiUnq4IVBn5NfiPEvVYEJiiXWS+n EvuvNwzzR8yjBdB80o1UHLJYXkdZRrpSF83uk7uKfEz2eRwCScYljdh/zCTGQpJ6F2/k GDHw== Received: by 10.204.129.196 with SMTP id p4mr9243186bks.97.1352926892968; Wed, 14 Nov 2012 13:01:32 -0800 (PST) Received: from [192.168.0.7] (b0fb0621.bb.sky.com. [176.251.6.33]) by mx.google.com with ESMTPS id z22sm9077368bkw.2.2012.11.14.13.01.31 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 13:01:31 -0800 (PST) Message-ID: <50A406AD.8070902@gmail.com> Date: Wed, 14 Nov 2012 21:01:33 +0000 From: Lionel Landwerlin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121031 Icedove/16.0.2 MIME-Version: 1.0 To: clutter-list@gnome.org Subject: Re: distro for Clutter 1.12? References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020305070106060709010909" X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:01:41 -0000 This is a multi-part message in MIME format. --------------020305070106060709010909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm running Gnome 3.6 with Clutter 1.12 on Debian (experimental though...) -Lionel On 14/11/12 20:58, Brian Duffy wrote: > After reading some of the mailing list threads for Fedora 18 > development, I am wondering if there is another distribution that is > recently released (or soon to be) that includes Clutter 1.12? > > Personally, I don't like trying to maintain my own cutting edge dev > environment. I depend on the distro to have the latest available > packages for Clutter, Vala, etc. Normally, I would just wait for > Fedora, but those Anaconda discussions have me spooked. > > Any suggestions? > > thnx > > Brian > > -- > Duff > > > _______________________________________________ > clutter-list mailing list > clutter-list@gnome.org > https://mail.gnome.org/mailman/listinfo/clutter-list --------------020305070106060709010909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I'm running Gnome 3.6 with Clutter 1.12 on Debian (experimental though...)

-Lionel

On 14/11/12 20:58, Brian Duffy wrote:
After reading some of the mailing list threads for Fedora 18 development, I am wondering if there is another distribution that is recently released (or soon to be) that includes Clutter 1.12? 

Personally, I don't like trying to maintain my own cutting edge dev environment. I depend on the distro to have the latest available packages for Clutter, Vala, etc. Normally, I would just wait for Fedora, but those Anaconda discussions have me spooked. 

Any suggestions?

thnx

Brian

--
Duff


_______________________________________________
clutter-list mailing list
clutter-list@gnome.org
https://mail.gnome.org/mailman/listinfo/clutter-list

--------------020305070106060709010909-- From arslan.atajanov@gmail.com Wed Nov 14 21:03:12 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F200575059F; Wed, 14 Nov 2012 21:03:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TW_HN=0.077] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiKtUugvGsB0; Wed, 14 Nov 2012 21:02:57 +0000 (UTC) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by menubar.gnome.org (Postfix) with ESMTP id BEB5D750566; Wed, 14 Nov 2012 21:02:56 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1230120lah.27 for ; Wed, 14 Nov 2012 13:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eKAqa3OaQJOkRdxsPkiWV75pKeTzYrMgy42RTkvljl8=; b=TovGXGqSRuRTvZSOGB9kEN3Bw4vVMv0JBOnmcelo4FXgGfnC6s8MV32bMQAdL1DBwM FexoNwOOHvVzKpEpAfndDEhIVc/tjDjJBN24iXlFJIj5w6oSfNOlRbaQa4oBwISdTAAu rEVW8DnCE9IwCudkXUQZStjmo+jcPaWuHu3pxFf0OkwvENA6JOIiiru0oX8uff67EWGh QoG5kqdQa7YazHVwxLSrI8kHYhxuLlkgXjCTXjmmiQTuJU6FM3AC2fzK2n5Se+gL5anq e8Y0sk31shTxv54qEtAkVqy9CQrQ68j1A8chZa4jNpE3SDZ2JFwlHkNrw9bJekRzwIKo H7Ig== MIME-Version: 1.0 Received: by 10.112.103.135 with SMTP id fw7mr11224189lbb.16.1352926973909; Wed, 14 Nov 2012 13:02:53 -0800 (PST) Received: by 10.152.124.170 with HTTP; Wed, 14 Nov 2012 13:02:53 -0800 (PST) Received: by 10.152.124.170 with HTTP; Wed, 14 Nov 2012 13:02:53 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 21:02:53 +0000 Message-ID: Subject: Re: distro for Clutter 1.12? From: "arslan.atajanov@gmail.com" To: Brian Duffy Content-Type: multipart/alternative; boundary=14dae9d7181aafdaaa04ce7adb1b Cc: clutter-list@gnome.org, "gnome-love@gnome.org" X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:03:12 -0000 --14dae9d7181aafdaaa04ce7adb1b Content-Type: text/plain; charset=ISO-8859-1 Hi, My suggestion is ArchLinux. They have already updated clutter 1.12 in their repos. -Arslan On Nov 14, 2012 8:59 PM, "Brian Duffy" wrote: > After reading some of the mailing list threads for Fedora 18 development, > I am wondering if there is another distribution that is recently released > (or soon to be) that includes Clutter 1.12? > > Personally, I don't like trying to maintain my own cutting edge dev > environment. I depend on the distro to have the latest available packages > for Clutter, Vala, etc. Normally, I would just wait for Fedora, but those > Anaconda discussions have me spooked. > > Any suggestions? > > thnx > > Brian > > -- > Duff > > _______________________________________________ > clutter-list mailing list > clutter-list@gnome.org > https://mail.gnome.org/mailman/listinfo/clutter-list > > --14dae9d7181aafdaaa04ce7adb1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

My suggestion is ArchLinux. They have already updated clutter 1.12 in th= eir repos.

-Arslan

On Nov 14, 2012 8:59 PM, "Brian Duffy"= <brduffy@gmail.com> wrote:<= br type=3D"attribution">
After reading some of the mailing list threads for Fedora 18 development, I= am wondering if there is another distribution that is recently released (o= r soon to be) that includes Clutter 1.12?=A0

Personally,= I don't like trying to maintain my own cutting edge dev environment. I= depend on the distro to have the latest available packages for Clutter, Va= la, etc. Normally, I would just wait for Fedora, but those Anaconda discuss= ions have me spooked.=A0

Any suggestions?

thnx

Brian

--
Duff

_______________________________________________
clutter-list mailing list
clutter-list@gnome.org
https://mail.gnome.org/mailman/listinfo/clutter-list

--14dae9d7181aafdaaa04ce7adb1b-- From mardy.tardi@gmail.com Thu Nov 15 13:25:03 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 285BF7503E2 for ; Thu, 15 Nov 2012 13:25:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdLcT99cQ3Kr for ; Thu, 15 Nov 2012 13:24:48 +0000 (UTC) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by menubar.gnome.org (Postfix) with ESMTP id 501377501E1 for ; Thu, 15 Nov 2012 13:24:48 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2171052lbb.27 for ; Thu, 15 Nov 2012 05:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=E4fJPhy7ZhN9NCTy0lmczZ9nYXp2pH8veHa9n6uZo7A=; b=u8o7hEH0yIWqKg1P0futpH163oiK/FWyjZhKZc+nNfnEhK9ccKPqgGZ4UYdgL5uGsN O1ML/YNXhHwSbfxV+JIhPMzRDQ5b+B4nHUrDs73DqMSznyUfKhvYPtVQ8CPHTIErjP2D RiyPMQhFN8E8O/a2MVVxEuTnRPNbK7oJSDshPEdZDR/mkeZ0kar2bH4DyS5PkuqZwBED XmmF2WXxhz2uJ8cNnUTueKYWKwMv8F4JLSNPFCgOECKTCNVq8Nq0vXDV6bEzmEDP/ead vRHXqympvivQTvTXZeOOoh7SiN8P1+hswJiKwV6/ytadFHD+q8TDi0DAzvwl9pGEVJl+ 6udA== Received: by 10.152.105.103 with SMTP id gl7mr1067865lab.10.1352985886228; Thu, 15 Nov 2012 05:24:46 -0800 (PST) Received: from [192.168.100.102] (a88-114-100-24.elisa-laajakaista.fi. [88.114.100.24]) by mx.google.com with ESMTPS id z9sm6252857lbk.15.2012.11.15.05.24.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 05:24:45 -0800 (PST) Sender: Alberto Mardegan Message-ID: <50A4ED21.5090701@users.sourceforge.net> Date: Thu, 15 Nov 2012 15:24:49 +0200 From: Alberto Mardegan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: clutter-list@gnome.org Subject: Re: distro for Clutter 1.12? References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:25:03 -0000 On 11/14/2012 10:58 PM, Brian Duffy wrote: > After reading some of the mailing list threads for Fedora 18 > development, I am wondering if there is another distribution that is > recently released (or soon to be) that includes Clutter 1.12? Ubuntu 12.10. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! From brduffy@gmail.com Thu Nov 15 14:31:21 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 375C37500B9 for ; Thu, 15 Nov 2012 14:31:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9jdbN1GKWtE for ; Thu, 15 Nov 2012 14:31:02 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by menubar.gnome.org (Postfix) with ESMTP id 01AB67508E3 for ; Thu, 15 Nov 2012 14:31:01 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so1423758pab.27 for ; Thu, 15 Nov 2012 06:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=adGurlgxhdPwemlSOH5mFZN81QF9IzRtalNVF5xTMDY=; b=dTHHMOXlWVmBCjMKWEMVS+ku4LtJjR6Mfg2DTLTk/EqTBg2+dyZNN3hqmz8QpQiWYY FErCy3GpQrgdCXk3PGpSuiHtak95GwLUrcDjDi9/I9aahjc70baCtHydZEV//1c4L3mp BZ5LiLav4Pfy1CM5vRPGfAxhU78sPDUVm1M+JoD7/lsR63ZqSMl+gdMRmbS1jcf1rUqn qpU6QsPErg54HIUNILynTPs4sVNGHQehNPQQXNtxhP/HhvaMEmHl9XaxMn1Fhy5pGZKH gtrbg9b/HtZFB6yEtocdlu2afzd2aUIw5cZqZ3gaCbz4FnUsLJtheG2zuffkXhBQOYkX Xr7w== MIME-Version: 1.0 Received: by 10.68.224.8 with SMTP id qy8mr5260098pbc.88.1352989860468; Thu, 15 Nov 2012 06:31:00 -0800 (PST) Received: by 10.66.222.132 with HTTP; Thu, 15 Nov 2012 06:31:00 -0800 (PST) In-Reply-To: <50A4ED21.5090701@users.sourceforge.net> References: <50A4ED21.5090701@users.sourceforge.net> Date: Thu, 15 Nov 2012 09:31:00 -0500 Message-ID: Subject: Re: distro for Clutter 1.12? From: Brian Duffy To: Alberto Mardegan Content-Type: multipart/alternative; boundary=047d7b16052b0496be04ce898008 Cc: clutter-list@gnome.org X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 14:31:21 -0000 --047d7b16052b0496be04ce898008 Content-Type: text/plain; charset=ISO-8859-1 Thanks. For now, I may go with Ubuntu since it is the easiest solution. I like that Arch continuously updates its packages without me having to wait six or nine months for a new release. When I have some more time I think I will try and get an arch linux environment going and see how that turns out. On Thu, Nov 15, 2012 at 8:24 AM, Alberto Mardegan < mardy@users.sourceforge.net> wrote: > On 11/14/2012 10:58 PM, Brian Duffy wrote: > > After reading some of the mailing list threads for Fedora 18 > > development, I am wondering if there is another distribution that is > > recently released (or soon to be) that includes Clutter 1.12? > > Ubuntu 12.10. > > Ciao, > Alberto > > -- > http://blog.mardy.it <- geek in un lingua international! > _______________________________________________ > clutter-list mailing list > clutter-list@gnome.org > https://mail.gnome.org/mailman/listinfo/clutter-list > -- Duff --047d7b16052b0496be04ce898008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks. For now, I may go with Ubuntu since it is the easiest solution. I l= ike that Arch continuously updates its packages without me having to wait s= ix or nine months for a new release. When I have some more time I think I w= ill try and get an arch linux environment going and see how that turns out.=


On Thu, Nov 15, 2012 at 8:24 AM, Alberto= Mardegan <mardy@users.sourceforge.net> wrote:
=
On 11/14/2012 10:58 PM, Brian Duffy wrote:
> After reading some of the mailing list threads for Fedora 18
> development, I am wondering if there is another distribution that is > recently released (or soon to be) that includes Clutter 1.12?

Ubuntu 12.10.

Ciao,
=A0 Alberto

--
http://blog.mardy.it= <- geek in un lingua international!
_____________________= __________________________
clutter-list mailing list
clutter-list@gnome.org
https://mail.gnome.org/mailman/listinfo/clutter-list



--
= Duff
--047d7b16052b0496be04ce898008-- From muelli@cryptobitch.de Thu Nov 15 23:53:22 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 07B0C7501A3 for ; Thu, 15 Nov 2012 23:53:22 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.115, TW_GT=0.077] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esodFMTPnF4q for ; Thu, 15 Nov 2012 23:53:20 +0000 (UTC) Received: from mail.cryptobitch.de (cryptobitch.de [88.198.7.68]) by menubar.gnome.org (Postfix) with ESMTP id AC1F4750171 for ; Thu, 15 Nov 2012 23:53:19 +0000 (UTC) Received: from [192.168.0.107] (unknown [46.59.217.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.cryptobitch.de (Postfix) with ESMTPSA id D1C165F72E8 for ; Fri, 16 Nov 2012 00:53:17 +0100 (CET) Message-ID: <50A5806D.6030104@cryptobitch.de> Date: Fri, 16 Nov 2012 00:53:17 +0100 From: Tobias Mueller User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: clutter-list@gnome.org Subject: Fwd: broken web link References: <8954.1351396927@tristatelogic.com> In-Reply-To: <8954.1351396927@tristatelogic.com> X-Enigmail-Version: 1.4.5 X-Forwarded-Message-Id: <8954.1351396927@tristatelogic.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:53:22 -0000 FYI -------- Original Message -------- Subject: broken web link Date: Sat, 27 Oct 2012 21:02:07 -0700 From: Ronald F. Guilmette To: webmaster@gnome.org On this page: http://blogs.gnome.org/clutter/ there is a link to: http://ftp.gnome.org/pub/GNOME/source/clutter-gtk unfortunately, the page in question is coming up as "404 Not Found". _______________________________________________ gnome-web-list mailing list gnome-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-web-list From pshirkey@boosthardware.com Fri Nov 16 10:51:35 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id F3DA37502EC for ; Fri, 16 Nov 2012 10:51:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.114] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlarjVSxraf9 for ; Fri, 16 Nov 2012 10:51:17 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id D9AFF75030D for ; Fri, 16 Nov 2012 10:51:16 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id B5DB140003; Fri, 16 Nov 2012 11:51:11 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Fri, 16 Nov 2012 21:51:11 +1100 (EST) Message-ID: <45993.188.25.63.54.1353063071.squirrel@boosthardware.com> In-Reply-To: <43430.188.25.63.54.1352886996.squirrel@boosthardware.com> References: <43430.188.25.63.54.1352886996.squirrel@boosthardware.com> Date: Fri, 16 Nov 2012 21:51:11 +1100 (EST) Subject: Re: [clutter] color change delay From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:51:35 -0000 On Wed, November 14, 2012 8:56 pm, Patrick Shirkey wrote: > Hi, > > I am seeing a delay of upto 4 seconds to change the color of an actor on > button-press-event. > > Does anyone have a suggestion to make the response time faster? > > Print statements in the event handler function are immediately written to > console so the delay seems to be deeper in the event handling stack. > > I managed to decrease the color change delay on button-press-event by using Clutter.Rectangle() for the grid pattern (>1500 actors) so I am only using the RoundRectangle() class from the pyclutter-widgets project on the keyboard buttons. It's still not completely snappy so it must be an inefficiency in the RoundRectangle() class or Shapes() class from pyclutter-widgets. -- Patrick Shirkey Boost Hardware Ltd From pshirkey@boosthardware.com Fri Nov 16 10:51:37 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9D64B750325 for ; Fri, 16 Nov 2012 10:51:37 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.114] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bNl1l3BFXB9 for ; Fri, 16 Nov 2012 10:51:23 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id 66EEB7502D7 for ; Fri, 16 Nov 2012 10:51:23 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id 1E3FB40003; Fri, 16 Nov 2012 11:51:19 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Fri, 16 Nov 2012 21:51:19 +1100 (EST) Message-ID: <45993.188.25.63.54.1353063079.squirrel@boosthardware.com> Date: Fri, 16 Nov 2012 21:51:19 +1100 (EST) Subject: [clutter] modifier keys From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:51:37 -0000 Hi, I found this example for using modifiers. http://markmail.org/download.xqy?id=mzxu3obfvyu4px53&number=1 I also tried to use the key_bindings method but couldn't work it out for python3. http://developer.gnome.org/clutter/stable/clutter-Key-Bindings.html#clutter-binding-pool-install-action With the first option I see the following behaviour. ctrl+F1 not ok ctrl+F2 ok shift+F1 ok shift+F2 ok meta(alt) + f1/f2 is overridden by gnome3. I really need meta to work for this application. Is there a better way to handle alt/meta modifiers and ctrl+F1 that will definitely work? -- Patrick Shirkey Boost Hardware Ltd From tf+lists.clutter@r-finger.com Sat Nov 17 18:01:42 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 48F997503E3 for ; Sat, 17 Nov 2012 18:01:42 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.115] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Towxa-skonrK for ; Sat, 17 Nov 2012 18:01:30 +0000 (UTC) X-Greylist: delayed 533 seconds by postgrey-1.34 at menubar.gnome.org; Sat, 17 Nov 2012 18:01:30 UTC Received: from r-finger.com (r-finger.com [178.79.160.5]) by menubar.gnome.org (Postfix) with ESMTP id 2CCF47503E1 for ; Sat, 17 Nov 2012 18:01:29 +0000 (UTC) Received: from [192.168.0.2] (host81-147-178-119.range81-147.btcentralplus.com [81.147.178.119]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by r-finger.com (Postfix) with ESMTPSA id D234E9BE3 for ; Sat, 17 Nov 2012 17:52:34 +0000 (GMT) Message-ID: <50A7CEE2.8020506@r-finger.com> Date: Sat, 17 Nov 2012 17:52:34 +0000 From: Tomas Frydrych User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: clutter-list@gnome.org Subject: Re: [clutter] modifier keys References: <45993.188.25.63.54.1353063079.squirrel@boosthardware.com> In-Reply-To: <45993.188.25.63.54.1353063079.squirrel@boosthardware.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 18:01:42 -0000 On 16/11/12 10:51, Patrick Shirkey wrote: > ctrl+F1 not ok > ctrl+F2 ok > shift+F1 ok > shift+F2 ok > meta(alt) + f1/f2 is overridden by gnome3. > > I really need meta to work for this application. Is there a better way to > handle alt/meta modifiers and ctrl+F1 that will definitely work? The Window Manager gets the first claim on any key events, so anything the WM uses your application will not get to see (whether your app uses clutter, or gtk, or xlib does not matter) -- if you want to use the WM's shortcut keys for your app, you will need to make the WM to use something else in their place. (In principle, it is possible to monitor all key events using the XI2 raw key events, but this will not make them 'yours', and the WM will still handle them the normal way, so this has only limited uses.) Tomas From pshirkey@boosthardware.com Fri Nov 23 19:48:14 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C47D8751232 for ; Fri, 23 Nov 2012 19:48:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.365] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5K3EAHBP1gP for ; Fri, 23 Nov 2012 19:48:10 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id D0201751112 for ; Fri, 23 Nov 2012 19:48:09 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id 0DA3140003; Fri, 23 Nov 2012 20:48:01 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Sat, 24 Nov 2012 06:48:01 +1100 (EST) Message-ID: <54814.188.25.63.54.1353700081.squirrel@boosthardware.com> Date: Sat, 24 Nov 2012 06:48:01 +1100 (EST) Subject: [clutter] Threaded widget generation From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 19:48:15 -0000 Hi, In an attempt to decrease the build time for my grid with thousands of actors I am looking at threading options. It currently takes about 5 seconds to build 25 rows with 130 actors in each row. That's adding approx 5500 clutter.Rectangle()'s to a Clutter.ScrollActor() on my dual core 1.8Ghz with 2048 MB RAM. I am interested in threading options for clutter. Is there a way to leverage multicore GPU's during the widget generation process or is that only handled by the CPU? Either way is there a recommendation for number of threads to use or a more efficient method when generating a large grid of actors? The target system is a quad core with 8GB RAM so things might be faster with a single "page" of 12 rows but I would like to support smooth scrolling with upto 1024 rows or 85 "pages". -- Patrick Shirkey Boost Hardware Ltd From ebassi@gmail.com Fri Nov 23 20:33:43 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id DC1AF750F83 for ; Fri, 23 Nov 2012 20:33:43 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob4b651ttHvy for ; Fri, 23 Nov 2012 20:33:41 +0000 (UTC) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by menubar.gnome.org (Postfix) with ESMTP id 9DEB5750B06 for ; Fri, 23 Nov 2012 20:33:41 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so16284715obc.27 for ; Fri, 23 Nov 2012 12:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7zZQPbOi/uK1PdrNqblF5xyXvM8vAnVEKx+zLcfLLB0=; b=HNmYpArhnmw6oo1jH04Bbakrmm1SNHRKL4dUAS8GvQxc309uMUR3ZJRJ3mqPcdJgq7 gt/MMAj9CFFg4iRBgUhsojxy9JnHX4TocaglN/HRPwwPhQxlF+tjMKkQk3A4rAsfBRJD xHPLak4Awf8I/vXv7/70d4Jv6KkIoHLcmG5pjyAnterez/uxWUU4R1LJpElxxAfVj5o9 efvzB7K2/KqxLTM76egjO+crQw7PWpfM7Nw5ODDPcrgaGWo/l9vw7DOjtqUf+B13x4y/ 6FsZsGgPcEMQO4qV8dSwFI+s7eQbNg4QA+cd6nd7FnLOiu1dcSjFEHVyaVAwf47VirAn wLJQ== MIME-Version: 1.0 Received: by 10.182.89.42 with SMTP id bl10mr3816312obb.27.1353702819923; Fri, 23 Nov 2012 12:33:39 -0800 (PST) Received: by 10.76.28.10 with HTTP; Fri, 23 Nov 2012 12:33:39 -0800 (PST) In-Reply-To: <54814.188.25.63.54.1353700081.squirrel@boosthardware.com> References: <54814.188.25.63.54.1353700081.squirrel@boosthardware.com> Date: Fri, 23 Nov 2012 20:33:39 +0000 Message-ID: Subject: Re: [clutter] Threaded widget generation From: Emmanuele Bassi To: Patrick Shirkey Content-Type: text/plain; charset=UTF-8 Cc: clutter-list@gnome.org X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 20:33:44 -0000 hi; On 23 November 2012 19:48, Patrick Shirkey wrote: > In an attempt to decrease the build time for my grid with thousands of > actors I am looking at threading options. It currently takes about 5 > seconds to build 25 rows with 130 actors in each row. That's adding approx > 5500 clutter.Rectangle()'s to a Clutter.ScrollActor() on my dual core > 1.8Ghz with 2048 MB RAM. though I think this is not a great design decision on your part, allocating 5000 actors is not going to be a problem. even adding them to a container won't take much; though using add_child() will try to keep the list sorted, which will result in a O(n log n) behaviour, most likely, so you'll probably want to use insert_child_above() or insert_child_below(), which are constant time operations. you're also probably invalidating the scene graph multiple times - and if you are just adding rectangles in a loop, you're most likely blocking the main loop, and thus blocking the interactive execution of your application. > I am interested in threading options for clutter. the current, and only, option right now is: do not. you cannot call Clutter API from different threads. > Either way is there a recommendation for number of threads to use or a > more efficient method when generating a large grid of actors? pack sibling nodes inside a container, and then add the container to the parent, so that you can avoid recursive invalidations inside the scene graph. use constant time operations wherever possible. do not block the main loop with your own loops: use lazy loading through callbacks inside the main loop, like the ones provided by g_idle_add() or g_timeout_add(). > The target system is a quad core with 8GB RAM so things might be faster > with a single "page" of 12 rows but I would like to support smooth > scrolling with upto 1024 rows or 85 "pages". my design suggestion is to have a screen with predefined rows, and instead change the contents of the actors, instead of a huge grid that you have to translate in order to scroll. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ From pshirkey@boosthardware.com Sat Nov 24 12:38:13 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 28A83750D27 for ; Sat, 24 Nov 2012 12:38:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.37] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgUmYVbh8fiH for ; Sat, 24 Nov 2012 12:38:10 +0000 (UTC) Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) by menubar.gnome.org (Postfix) with ESMTP id 7E8A3750C16 for ; Sat, 24 Nov 2012 12:38:09 +0000 (UTC) Received: by boosthardware.localdomain (Postfix, from userid 48) id 1A72240003; Sat, 24 Nov 2012 13:38:04 +0100 (CET) Received: from 188.25.63.54 (SquirrelMail authenticated user pshirkey@boosthardware.com) by boosthardware.com with HTTP; Sat, 24 Nov 2012 23:38:04 +1100 (EST) Message-ID: <61376.188.25.63.54.1353760684.squirrel@boosthardware.com> In-Reply-To: References: <54814.188.25.63.54.1353700081.squirrel@boosthardware.com> Date: Sat, 24 Nov 2012 23:38:04 +1100 (EST) Subject: Re: [clutter] Threaded widget generation From: "Patrick Shirkey" To: clutter-list@gnome.org User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 12:38:13 -0000 On Sat, November 24, 2012 7:33 am, Emmanuele Bassi wrote: > hi; > > On 23 November 2012 19:48, Patrick Shirkey > wrote: > >> In an attempt to decrease the build time for my grid with thousands of >> actors I am looking at threading options. It currently takes about 5 >> seconds to build 25 rows with 130 actors in each row. That's adding >> approx >> 5500 clutter.Rectangle()'s to a Clutter.ScrollActor() on my dual core >> 1.8Ghz with 2048 MB RAM. > Thanks for your detailed reply. > though I think this is not a great design decision on your part, > allocating 5000 actors is not going to be a problem. even adding them > to a container won't take much; though using add_child() will try to > keep the list sorted, which will result in a O(n log n) behaviour, > most likely, so you'll probably want to use insert_child_above() or > insert_child_below(), which are constant time operations. you're also > probably invalidating the scene graph multiple times - and if you are > just adding rectangles in a loop, you're most likely blocking the main > loop, and thus blocking the interactive execution of your application. > At the moment I am just using scrollActor.add_actor(). Is insert_child_[below/after]() faster than add_actor()? >> I am interested in threading options for clutter. > > the current, and only, option right now is: do not. > > you cannot call Clutter API from different threads. > >> Either way is there a recommendation for number of threads to use or a >> more efficient method when generating a large grid of actors? > > pack sibling nodes inside a container, and then add the container to > the parent, so that you can avoid recursive invalidations inside the > scene graph. > To paraphrase, it's more efficient to destroy the container, create a new container, add the children to the container and then add the container to the parent after all the child actors have been built? > use constant time operations wherever possible. > > do not block the main loop with your own loops: use lazy loading > through callbacks inside the main loop, like the ones provided by > g_idle_add() or g_timeout_add(). > This is what I was trying to get at with threading. Is there an example somewhere of handling g_idle_add/g_timeout_add with a large array of actors? Ex. Is there an example of a clutter "spinner" type widget somewhere for loading large external datasets (web/db)? >> The target system is a quad core with 8GB RAM so things might be faster >> with a single "page" of 12 rows but I would like to support smooth >> scrolling with upto 1024 rows or 85 "pages". > > my design suggestion is to have a screen with predefined rows, and > instead change the contents of the actors, instead of a huge grid that > you have to translate in order to scroll. > You may be surprised to know that the actual scrolling of the grid with a large number of rows works smoothly on this machine in all directions with "EASE_OUT" for the easing mode. It's just the time it takes to build and display the widget that I am interested in maximising efficiency at this point. -- Patrick Shirkey Boost Hardware Ltd From ebassi@gmail.com Sat Nov 24 18:43:49 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 4BD197514B8 for ; Sat, 24 Nov 2012 18:43:49 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLQTOMsrLHbI for ; Sat, 24 Nov 2012 18:43:35 +0000 (UTC) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by menubar.gnome.org (Postfix) with ESMTP id E4BCD751487 for ; Sat, 24 Nov 2012 18:43:34 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so17208241obc.27 for ; Sat, 24 Nov 2012 10:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l+fAlQWw41PCAhqcZeQ9NgSw0mCXo/H2RQh/6K8XutE=; b=Wd18y8LDqxn2ZGsQ4ysxR2L+dqHhN5ERNREwBP48Qc9cs93rlArsLb45qSU1dr/2Cf ZmAOabogHNSQE3rvlwNB8H0tlxdFGkoiPfYogBnToDskGUcDzFhzDdeMkP+AEchNO/zR IEyLtWISrF9B1DYiRQI6zGHJX2WH5eNX0WIthTIu1DgEpu7+Gv+WDWZbHfHqehhMqF4h mh5lxhXAU3mOfdyJ4EavgfgNvUokjI+HRmwvsRCpVnmSnGkiKI8lJ3n+7lz73DdUCqnx 3ZhYVi3niJQstqf4g9nz4NFR57A1k6mWifLZyhFHBvxP2Rc3d7s3NvYIqD58ySgBE/OK 6d2A== MIME-Version: 1.0 Received: by 10.182.89.42 with SMTP id bl10mr5677839obb.27.1353782613226; Sat, 24 Nov 2012 10:43:33 -0800 (PST) Received: by 10.76.28.10 with HTTP; Sat, 24 Nov 2012 10:43:33 -0800 (PST) In-Reply-To: <61376.188.25.63.54.1353760684.squirrel@boosthardware.com> References: <54814.188.25.63.54.1353700081.squirrel@boosthardware.com> <61376.188.25.63.54.1353760684.squirrel@boosthardware.com> Date: Sat, 24 Nov 2012 18:43:33 +0000 Message-ID: Subject: Re: [clutter] Threaded widget generation From: Emmanuele Bassi To: Patrick Shirkey Content-Type: text/plain; charset=UTF-8 Cc: clutter-list@gnome.org X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 18:43:49 -0000 hi; On 24 November 2012 12:38, Patrick Shirkey wrote: > At the moment I am just using scrollActor.add_actor(). Clutter.Actor.add_child() (which is what the deprecated Clutter.Container.add_actor() internally calls) tries to maintain the list of children sorted using the :depth/:z-position property as the sorting key; sadly, we need to maintain that invariant for backwards compatibility, though it's a stupid thing to do (and won't be done any more in 2.0). since insert_child_above/below_sibling() were introduced afterwards, and since they are based on explicit ordering, I could implement them as constant time operations. if you are building a row of actors then you probably want to use them, since you already have an implicit order you want to use. >> pack sibling nodes inside a container, and then add the container to >> the parent, so that you can avoid recursive invalidations inside the >> scene graph. >> > > To paraphrase, it's more efficient to destroy the container, create a new > container, add the children to the container and then add the container > to the parent after all the child actors have been built? yes; the invalidations necessary when adding children will traverse the scene graph (something we're trying to optimize), so if the scene graph is shallow, they will stop sooner. >> use constant time operations wherever possible. >> >> do not block the main loop with your own loops: use lazy loading >> through callbacks inside the main loop, like the ones provided by >> g_idle_add() or g_timeout_add(). >> > > This is what I was trying to get at with threading. Is there an example > somewhere of handling g_idle_add/g_timeout_add with a large array of > actors? I wrote this article years ago, to deal with GtkTreeModel implementations inside gtk: http://blogs.gnome.org/ebassi/documentation/lazy-loading/ the concept still applies: you create a simple state machine, pass the list of actors to add (possibly already ordered) to the callback function you use with idle_add(), and iterate over the list inserting a single child (or a small batch, depending on your time constraints) for each iteration. once the list has been consumed, you remove the idle handler. > Ex. Is there an example of a clutter "spinner" type widget somewhere for > loading large external datasets (web/db)? no, not really; though creating a texture with an image, and then animating its rotation angle using a PropertyTransition() with repeat_count=-1 would do. >>> The target system is a quad core with 8GB RAM so things might be faster >>> with a single "page" of 12 rows but I would like to support smooth >>> scrolling with upto 1024 rows or 85 "pages". >> >> my design suggestion is to have a screen with predefined rows, and >> instead change the contents of the actors, instead of a huge grid that >> you have to translate in order to scroll. >> > > You may be surprised to know that the actual scrolling of the grid with a > large number of rows works smoothly on this machine in all directions with > "EASE_OUT" for the easing mode. I'm not overly surprised: ScrollActor uses transformations to achieve the scrolling effect, which means that the scene graph is not invalidated at all. :-) > It's just the time it takes to build and > display the widget that I am interested in maximising efficiency at this > point. lazily loading actors and data is usually a good technique, especially when dealing with libraries like Clutter which are based on a main loop. also, as I said, trying to use as many constant time operations - or even linear time operations with a small input - usually allows you to preserve as much of your time budget (which is 16 milliseconds, for 60fps) as possible. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ From otaylor@redhat.com Tue Nov 27 15:19:13 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CF9CB751B17 for ; Tue, 27 Nov 2012 15:19:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.27 X-Spam-Level: X-Spam-Status: No, score=-7.27 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.368, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LZTehTnArN9 for ; Tue, 27 Nov 2012 15:19:08 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by menubar.gnome.org (Postfix) with ESMTP id D27F175199E for ; Tue, 27 Nov 2012 15:19:08 +0000 (UTC) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARFJ7t8030847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Nov 2012 10:19:07 -0500 Received: from lagrange.redhat.com (ovpn-113-141.phx2.redhat.com [10.3.113.141]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARFJ6fu026858 for ; Tue, 27 Nov 2012 10:19:07 -0500 From: otaylor@redhat.com To: clutter-list@gnome.org Subject: Cogl patches supporting frame timing Date: Tue, 27 Nov 2012 10:18:56 -0500 Message-Id: <1354029539-29902-1-git-send-email-otaylor@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:19:14 -0000 This is a patch set for Cogl that adds support for reporting frame timing information back as necessary to get precise information about when frames were scanned out to the display device. What I've done with it so far is used this in the Mutter compositor to pass that information on to the application running and then used that in GTK+ for frame timing. With this approach, I can get audio/video synchronization in a test application to stably lock at a known millisecond rather than having an unknown latency somewhere in the 0-35 ms range. (This is in the wip/frame-synchronization branch of Cogl - there are corresponding wip/frame-synchronization branches of Clutter (small), Mutter, and GTK+) It's also useful to have information about what the refresh rate is of the display, so I've added a framework for CoglOutput to handle information about the properties of one display device. CoglOutput isn't fully hooked up yet - right now I'm just using it in the GLX winsys and not exposing it to applications. Other things that aren't completely finished here are: - I haven't really looked at other winsys - with some backends it may simply not be possible to get some or all of the information, and what I've done here is that any timing value can have a value of '0' as a flag to indicate that it isn't supplied. - I haven't tried to make Cogl a *consumer* of frame timing information from a X window system compositor - the same sort of work I've done for GTK+ should apply to the Cogl stack as well and may require a bit of adjustment when the timing information isn't coming directly from GL but instead from the compositor. From otaylor@redhat.com Tue Nov 27 15:19:33 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9E6137519B2 for ; Tue, 27 Nov 2012 15:19:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.193 X-Spam-Level: X-Spam-Status: No, score=-7.193 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.368, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GL=0.077] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqjRtoJ9GUiJ for ; Tue, 27 Nov 2012 15:19:25 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by menubar.gnome.org (Postfix) with ESMTP id 07BE775199E for ; Tue, 27 Nov 2012 15:19:25 +0000 (UTC) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARFJMoR004963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 10:19:22 -0500 Received: from lagrange.redhat.com (ovpn-113-141.phx2.redhat.com [10.3.113.141]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARFJ6fv026858; Tue, 27 Nov 2012 10:19:21 -0500 From: otaylor@redhat.com To: clutter-list@gnome.org Subject: [PATCH 1/3] Add CoglOutput and track for the GLX backend Date: Tue, 27 Nov 2012 10:18:57 -0500 Message-Id: <1354029539-29902-2-git-send-email-otaylor@redhat.com> In-Reply-To: <1354029539-29902-1-git-send-email-otaylor@redhat.com> References: <1354029539-29902-1-git-send-email-otaylor@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: "Owen W. Taylor" X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:19:33 -0000 From: "Owen W. Taylor" The CoglOutput object represents one output such as a monitor or laptop panel, with information about attributes of the output such as the position of the output within the global coordinate space, and the refresh rate. We don't yet publically export the ability to get output information but we track it for the GLX backend, where we'll use it to track the refresh rate. --- cogl/Makefile.am | 3 + cogl/cogl-output-private.h | 50 ++++++ cogl/cogl-output.h | 87 ++++++++++ cogl/cogl-xlib-renderer-private.h | 11 ++ cogl/cogl-xlib-renderer.c | 327 ++++++++++++++++++++++++++++++++++++++ cogl/winsys/cogl-winsys-glx.c | 106 +++++++++++- cogl/winsys/cogl-winsys-private.h | 3 + configure.ac | 3 +- 8 files changed, 581 insertions(+), 9 deletions(-) create mode 100644 cogl/cogl-output-private.h create mode 100644 cogl/cogl-output.h diff --git a/cogl/Makefile.am b/cogl/Makefile.am index a73d3f8..022caf5 100644 --- a/cogl/Makefile.am +++ b/cogl/Makefile.am @@ -106,6 +106,7 @@ cogl_experimental_h = \ $(srcdir)/cogl-clip-state.h \ $(srcdir)/cogl-framebuffer.h \ $(srcdir)/cogl-onscreen.h \ + $(srcdir)/cogl-output.h \ $(srcdir)/cogl-vector.h \ $(srcdir)/cogl-euler.h \ $(srcdir)/cogl-quaternion.h \ @@ -345,6 +346,8 @@ cogl_sources_c = \ $(srcdir)/cogl-framebuffer.c \ $(srcdir)/cogl-onscreen-private.h \ $(srcdir)/cogl-onscreen.c \ + $(srcdir)/cogl-output-private.h \ + $(srcdir)/cogl-output.c \ $(srcdir)/cogl-profile.h \ $(srcdir)/cogl-profile.c \ $(srcdir)/cogl-flags.h \ diff --git a/cogl/cogl-output-private.h b/cogl/cogl-output-private.h new file mode 100644 index 0000000..05803de --- /dev/null +++ b/cogl/cogl-output-private.h @@ -0,0 +1,50 @@ +/* + * Cogl + * + * An object oriented GL/GLES Abstraction/Utility Layer + * + * Copyright (C) 2012 Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see . + * + * + */ + +#ifndef __COGL_OUTPUT_PRIVATE_H +#define __COGL_OUTPUT_PRIVATE_H + +#include "cogl-output.h" +#include "cogl-object-private.h" + +struct _CoglOutput +{ + CoglObject _parent; + + char *name; + + int x; /* Must be first field for _cogl_output_values_equal() */ + int y; + int width; + int height; + int mm_width; + int mm_height; + float refresh_rate; + CoglSubpixelOrder subpixel_order; +}; + +CoglOutput *_cogl_output_new (const char *name); +gboolean _cogl_output_values_equal (CoglOutput *output, + CoglOutput *other); + +#endif /* __COGL_OUTPUT_PRIVATE_H */ diff --git a/cogl/cogl-output.h b/cogl/cogl-output.h new file mode 100644 index 0000000..48da41f --- /dev/null +++ b/cogl/cogl-output.h @@ -0,0 +1,87 @@ +/* + * Cogl + * + * An object oriented GL/GLES Abstraction/Utility Layer + * + * Copyright (C) 2012 Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * . + * + * + * + * Authors: + * Owen Taylor + */ +#if !defined(__COGL_H_INSIDE__) && !defined(COGL_COMPILATION) +#error "Only can be included directly." +#endif + +#ifndef __COGL_OUTPUT_H +#define __COGL_OUTPUT_H + +#include +#include + +G_BEGIN_DECLS + +typedef struct _CoglOutput CoglOutput; +#define COGL_OUTPUT(X) ((CoglOutput *)(X)) + +typedef enum { + COGL_SUBPIXEL_ORDER_UNKNOWN, + COGL_SUBPIXEL_ORDER_NONE, + COGL_SUBPIXEL_ORDER_HORIZONTAL_RGB, + COGL_SUBPIXEL_ORDER_HORIZONTAL_BGR, + COGL_SUBPIXEL_ORDER_VERTICAL_RGB, + COGL_SUBPIXEL_ORDER_VERTICAL_BGR +} CoglSubpixelOrder; + +/** + * cogl_is_output: + * @object: A #CoglObject pointer + * + * Gets whether the given object references a #CoglOutput. + * + * Return value: %TRUE if the object references a #CoglOutput + * and %FALSE otherwise. + * Since: 2.0 + * Stability: unstable + */ +CoglBool +cogl_is_output (void *object); + +int +cogl_output_get_x (CoglOutput *output); +int +cogl_output_get_y (CoglOutput *output); +int +cogl_output_get_width (CoglOutput *output); +int +cogl_output_get_height (CoglOutput *output); +int +cogl_output_get_mm_width (CoglOutput *output); +int +cogl_output_get_mm_height (CoglOutput *output); +CoglSubpixelOrder +cogl_output_get_subpixel_order (CoglOutput *output); +float +cogl_output_get_refresh_rate (CoglOutput *output); + +G_END_DECLS + +#endif /* __COGL_OUTPUT_H */ + + + diff --git a/cogl/cogl-xlib-renderer-private.h b/cogl/cogl-xlib-renderer-private.h index 0c73b5c..cb3b60e 100644 --- a/cogl/cogl-xlib-renderer-private.h +++ b/cogl/cogl-xlib-renderer-private.h @@ -28,6 +28,7 @@ #include "cogl-xlib-private.h" #include "cogl-x11-renderer-private.h" #include "cogl-context.h" +#include "cogl-output.h" typedef struct _CoglXlibRenderer { @@ -41,6 +42,9 @@ typedef struct _CoglXlibRenderer /* A poll FD for handling event retrieval within Cogl */ CoglPollFD poll_fd; + + unsigned long outputs_update_serial; + GList *outputs; } CoglXlibRenderer; CoglBool @@ -92,4 +96,11 @@ _cogl_xlib_renderer_poll_dispatch (CoglRenderer *renderer, const CoglPollFD *poll_fds, int n_poll_fds); +CoglOutput * +_cogl_xlib_renderer_output_for_rectangle (CoglRenderer *renderer, + int x, + int y, + int width, + int height); + #endif /* __COGL_RENDERER_XLIB_PRIVATE_H */ diff --git a/cogl/cogl-xlib-renderer.c b/cogl/cogl-xlib-renderer.c index 9ae7765..fff3c35 100644 --- a/cogl/cogl-xlib-renderer.c +++ b/cogl/cogl-xlib-renderer.c @@ -33,6 +33,7 @@ #include "cogl-internal.h" #include "cogl-object.h" +#include "cogl-output-private.h" #include "cogl-renderer-private.h" #include "cogl-xlib-renderer-private.h" #include "cogl-x11-renderer-private.h" @@ -40,8 +41,10 @@ #include #include +#include #include +#include static char *_cogl_x11_display_name = NULL; static GList *_cogl_xlib_renderers = NULL; @@ -190,6 +193,271 @@ assert_xlib_display (CoglRenderer *renderer, GError **error) return xdpy; } +static int +compare_outputs (CoglOutput *a, + CoglOutput *b) +{ + return strcmp (a->name, b->name); +} + +#define CSO(X) COGL_SUBPIXEL_ORDER_ ## X +static CoglSubpixelOrder subpixel_map[6][6] = { + { CSO(UNKNOWN), CSO(NONE), CSO(HORIZONTAL_RGB), CSO(HORIZONTAL_BGR), CSO(VERTICAL_RGB), CSO(VERTICAL_BGR) }, /* 0 */ + { CSO(UNKNOWN), CSO(NONE), CSO(VERTICAL_RGB), CSO(VERTICAL_BGR), CSO(HORIZONTAL_BGR), CSO(HORIZONTAL_RGB) }, /* 90 */ + { CSO(UNKNOWN), CSO(NONE), CSO(HORIZONTAL_BGR), CSO(HORIZONTAL_RGB), CSO(VERTICAL_BGR), CSO(VERTICAL_RGB) }, /* 180 */ + { CSO(UNKNOWN), CSO(NONE), CSO(VERTICAL_BGR), CSO(VERTICAL_RGB), CSO(HORIZONTAL_RGB), CSO(HORIZONTAL_BGR) }, /* 270 */ + { CSO(UNKNOWN), CSO(NONE), CSO(HORIZONTAL_BGR), CSO(HORIZONTAL_RGB), CSO(VERTICAL_RGB), CSO(VERTICAL_BGR) }, /* Reflect_X */ + { CSO(UNKNOWN), CSO(NONE), CSO(HORIZONTAL_RGB), CSO(HORIZONTAL_BGR), CSO(VERTICAL_BGR), CSO(VERTICAL_RGB) }, /* Reflect_Y */ +}; +#undef CSO + +static void +update_outputs (CoglRenderer *renderer, + gboolean notify) +{ + CoglXlibRenderer *xlib_renderer = + _cogl_xlib_renderer_get_data (renderer); + XRRScreenResources *resources; + CoglXlibTrapState state; + gboolean error = FALSE; + GList *new_outputs = NULL; + GList *l, *m; + gboolean changed = FALSE; + int i; + + xlib_renderer->outputs_update_serial = XNextRequest (xlib_renderer->xdpy); + + resources = XRRGetScreenResources (xlib_renderer->xdpy, + DefaultRootWindow (xlib_renderer->xdpy)); + + _cogl_xlib_renderer_trap_errors (renderer, &state); + + for (i = 0; i < resources->ncrtc && !error; i++) + { + XRRCrtcInfo *crtc_info = NULL; + XRROutputInfo *output_info = NULL; + CoglOutput *output; + float refresh_rate = 0; + int j; + + crtc_info = XRRGetCrtcInfo (xlib_renderer->xdpy, resources, resources->crtcs[i]); + if (crtc_info == NULL) + { + error = TRUE; + goto next; + } + + if (crtc_info->mode == None) + goto next; + + for (j = 0; j < resources->nmode; j++) + { + if (resources->modes[j].id == crtc_info->mode) + refresh_rate = (resources->modes[j].dotClock / + ((float)resources->modes[j].hTotal * resources->modes[j].vTotal)); + } + + output_info = XRRGetOutputInfo (xlib_renderer->xdpy, + resources, + crtc_info->outputs[0]); + if (output_info == NULL) + { + error = TRUE; + goto next; + } + + output = _cogl_output_new (output_info->name); + output->x = crtc_info->x; + output->y = crtc_info->y; + output->width = crtc_info->width; + output->height = crtc_info->height; + if ((crtc_info->rotation & (RR_Rotate_90 | RR_Rotate_270)) != 0) + { + output->mm_width = output_info->mm_height; + output->mm_height = output_info->mm_width; + } + else + { + output->mm_width = output_info->mm_width; + output->mm_height = output_info->mm_height; + } + + output->refresh_rate = refresh_rate; + + switch (output_info->subpixel_order) + { + case SubPixelUnknown: + default: + output->subpixel_order = COGL_SUBPIXEL_ORDER_UNKNOWN; + break; + case SubPixelNone: + output->subpixel_order = COGL_SUBPIXEL_ORDER_NONE; + break; + case SubPixelHorizontalRGB: + output->subpixel_order = COGL_SUBPIXEL_ORDER_HORIZONTAL_RGB; + break; + case SubPixelHorizontalBGR: + output->subpixel_order = COGL_SUBPIXEL_ORDER_HORIZONTAL_BGR; + break; + case SubPixelVerticalRGB: + output->subpixel_order = COGL_SUBPIXEL_ORDER_VERTICAL_RGB; + break; + case SubPixelVerticalBGR: + output->subpixel_order = COGL_SUBPIXEL_ORDER_VERTICAL_BGR; + break; + } + + output->subpixel_order = COGL_SUBPIXEL_ORDER_HORIZONTAL_RGB; + + /* Handle the effect of rotation and reflection on subpixel order (ugh) */ + for (j = 0; j < 6; j++) + { + if ((crtc_info->rotation & (1 << j)) != 0) + output->subpixel_order = subpixel_map[j][output->subpixel_order]; + } + + new_outputs = g_list_prepend (new_outputs, output); + + next: + if (crtc_info != NULL) + XFree (crtc_info); + + if (output_info != NULL) + XFree (output_info); + } + + XFree (resources); + + if (!error) + { + new_outputs = g_list_sort (new_outputs, (GCompareFunc)compare_outputs); + + l = new_outputs; + m = xlib_renderer->outputs; + + while (l || m) + { + int cmp; + CoglOutput *output_l = l ? (CoglOutput *)l->data : NULL; + CoglOutput *output_m = m ? (CoglOutput *)m->data : NULL; + + if (l && m) + cmp = compare_outputs (output_l, output_m); + else if (l) + cmp = -1; + else + cmp = 1; + + if (cmp == 0) + { + GList *m_next = m->next; + + if (!_cogl_output_values_equal (output_l, output_m)) + { + xlib_renderer->outputs = g_list_remove_link (xlib_renderer->outputs, m); + xlib_renderer->outputs = g_list_insert_before (xlib_renderer->outputs , + m_next, output_l); + cogl_object_ref (output_l); + + changed = TRUE; + } + + l = l->next; + m = m_next; + } + else if (cmp < 0) + { + xlib_renderer->outputs = g_list_insert_before (xlib_renderer->outputs , + m, output_l); + cogl_object_ref (output_l); + changed = TRUE; + l = l->next; + } + else + { + GList *m_next = m->next; + xlib_renderer->outputs = g_list_remove_link (xlib_renderer->outputs, m); + changed = TRUE; + m = m_next; + } + } + } + + g_list_free_full (new_outputs, (GDestroyNotify)cogl_object_unref); + _cogl_xlib_renderer_untrap_errors (renderer, &state); + + if (changed) + { + const CoglWinsysVtable *winsys = renderer->winsys_vtable; + + if (notify) + COGL_NOTE (WINSYS, "Outputs changed:"); + else + COGL_NOTE (WINSYS, "Outputs:"); + + for (l = xlib_renderer->outputs; l; l = l->next) + { + CoglOutput *output = l->data; + const char *subpixel_string; + + switch (output->subpixel_order) + { + case COGL_SUBPIXEL_ORDER_UNKNOWN: + default: + subpixel_string = "unknown"; + break; + case COGL_SUBPIXEL_ORDER_NONE: + subpixel_string = "none"; + break; + case COGL_SUBPIXEL_ORDER_HORIZONTAL_RGB: + subpixel_string = "horizontal_rgb"; + break; + case COGL_SUBPIXEL_ORDER_HORIZONTAL_BGR: + subpixel_string = "horizontal_bgr"; + break; + case COGL_SUBPIXEL_ORDER_VERTICAL_RGB: + subpixel_string = "vertical_rgb"; + break; + case COGL_SUBPIXEL_ORDER_VERTICAL_BGR: + subpixel_string = "vertical_bgr"; + break; + } + + COGL_NOTE (WINSYS, + " %10s: +%d+%dx%dx%d mm=%dx%d dpi=%.1fx%.1f subpixel_order=%s refresh_rate=%.3f", + output->name, + output->x, output->y, output->width, output->height, + output->mm_width, output->mm_height, + output->width / (output->mm_width / 25.4), + output->height / (output->mm_height / 25.4), + subpixel_string, + output->refresh_rate); + } + + if (notify && winsys->renderer_outputs_changed != NULL) + winsys->renderer_outputs_changed (renderer); + } +} + +static CoglFilterReturn +randr_filter (XEvent *event, + void *data) +{ + CoglRenderer *renderer = data; + CoglXlibRenderer *xlib_renderer = + _cogl_xlib_renderer_get_data (renderer); + CoglX11Renderer *x11_renderer = + (CoglX11Renderer *) xlib_renderer; + + if (x11_renderer->randr_base != -1 && + (event->xany.type == x11_renderer->randr_base + RRScreenChangeNotify || + event->xany.type == x11_renderer->randr_base + RRNotify) && + event->xany.serial >= xlib_renderer->outputs_update_serial) + update_outputs (renderer, TRUE); + + return COGL_FILTER_CONTINUE; +} + CoglBool _cogl_xlib_renderer_connect (CoglRenderer *renderer, GError **error) { @@ -198,6 +466,7 @@ _cogl_xlib_renderer_connect (CoglRenderer *renderer, GError **error) CoglX11Renderer *x11_renderer = (CoglX11Renderer *) xlib_renderer; int damage_error; + int randr_error; if (!assert_xlib_display (renderer, error)) return FALSE; @@ -211,13 +480,30 @@ _cogl_xlib_renderer_connect (CoglRenderer *renderer, GError **error) &damage_error)) x11_renderer->damage_base = -1; + /* Check whether randr is supported on this display */ + if (!XRRQueryExtension (xlib_renderer->xdpy, + &x11_renderer->randr_base, + &randr_error)) + x11_renderer->randr_base = -1; + xlib_renderer->trap_state = NULL; xlib_renderer->poll_fd.fd = ConnectionNumber (xlib_renderer->xdpy); xlib_renderer->poll_fd.events = COGL_POLL_FD_EVENT_IN; + XRRSelectInput(xlib_renderer->xdpy, + DefaultRootWindow (xlib_renderer->xdpy), + RRScreenChangeNotifyMask + | RRCrtcChangeNotifyMask + | RROutputPropertyNotifyMask); + update_outputs (renderer, FALSE); + register_xlib_renderer (renderer); + cogl_xlib_renderer_add_filter (renderer, + randr_filter, + renderer); + return TRUE; } @@ -227,6 +513,10 @@ _cogl_xlib_renderer_disconnect (CoglRenderer *renderer) CoglXlibRenderer *xlib_renderer = _cogl_xlib_renderer_get_data (renderer); + g_list_free_full (xlib_renderer->outputs, + (GDestroyNotify)cogl_object_unref); + xlib_renderer->outputs = NULL; + if (!renderer->foreign_xdpy && xlib_renderer->xdpy) XCloseDisplay (xlib_renderer->xdpy); @@ -312,3 +602,40 @@ _cogl_xlib_renderer_poll_dispatch (CoglRenderer *renderer, cogl_xlib_renderer_handle_event (renderer, &xevent); } } + +CoglOutput * +_cogl_xlib_renderer_output_for_rectangle (CoglRenderer *renderer, + int x, + int y, + int width, + int height) +{ + CoglXlibRenderer *xlib_renderer = _cogl_xlib_renderer_get_data (renderer); + int max_overlap = 0; + CoglOutput *max_overlapped = NULL; + GList *l; + int xa1 = x, xa2 = x + width; + int ya1 = y, ya2 = y + height; + + for (l = xlib_renderer->outputs; l; l = l->next) + { + CoglOutput *output = l->data; + int xb1 = output->x, xb2 = output->x + output->width; + int yb1 = output->y, yb2 = output->y + output->height; + + int overlap_x = MIN(xa2, xb2) - MAX(xa1, xb1); + int overlap_y = MIN(ya2, yb2) - MAX(ya1, yb1); + + if (overlap_x > 0 && overlap_y > 0) + { + int overlap = overlap_x * overlap_y; + if (overlap > max_overlap) + { + max_overlap = overlap; + max_overlapped = output; + } + } + } + + return max_overlapped; +} diff --git a/cogl/winsys/cogl-winsys-glx.c b/cogl/winsys/cogl-winsys-glx.c index 839464f..e7f83ab 100644 --- a/cogl/winsys/cogl-winsys-glx.c +++ b/cogl/winsys/cogl-winsys-glx.c @@ -71,7 +71,9 @@ typedef struct _CoglContextGLX typedef struct _CoglOnscreenXlib { Window xwin; + int x, y; CoglBool is_foreign_xwin; + CoglOutput *output; } CoglOnscreenXlib; typedef struct _CoglOnscreenGLX @@ -185,29 +187,80 @@ notify_swap_buffers (CoglContext *context, GLXDrawable drawable) } static void +update_output (CoglOnscreen *onscreen) +{ + CoglOnscreenXlib *xlib_onscreen = onscreen->winsys; + CoglFramebuffer *framebuffer = COGL_FRAMEBUFFER (onscreen); + CoglContext *context = framebuffer->context; + CoglDisplay *display = context->display; + CoglOutput *output; + int width, height; + + width = cogl_framebuffer_get_width (framebuffer); + height = cogl_framebuffer_get_height (framebuffer); + output = _cogl_xlib_renderer_output_for_rectangle (display->renderer, + xlib_onscreen->x, xlib_onscreen->y, + width, height); + if (xlib_onscreen->output != output) + { + if (xlib_onscreen->output) + cogl_object_unref (xlib_onscreen->output); + + xlib_onscreen->output = output; + + if (output) + cogl_object_ref (xlib_onscreen->output); + } +} + +static void notify_resize (CoglContext *context, - GLXDrawable drawable, - int width, - int height) + XConfigureEvent *configure_event) { - CoglOnscreen *onscreen = find_onscreen_for_xid (context, drawable); + CoglOnscreen *onscreen = find_onscreen_for_xid (context, configure_event->window); CoglFramebuffer *framebuffer = COGL_FRAMEBUFFER (onscreen); CoglDisplay *display = context->display; CoglGLXDisplay *glx_display = display->winsys; CoglOnscreenGLX *glx_onscreen; + CoglOnscreenXlib *xlib_onscreen; if (!onscreen) return; glx_onscreen = onscreen->winsys; + xlib_onscreen = onscreen->winsys; - _cogl_framebuffer_winsys_update_size (framebuffer, width, height); + _cogl_framebuffer_winsys_update_size (framebuffer, configure_event->width, configure_event->height); /* We only want to notify that a resize happened when the application calls cogl_context_dispatch so instead of immediately notifying we'll set a flag to remember to notify later */ glx_display->pending_resize_notify = TRUE; glx_onscreen->pending_resize_notify = TRUE; + + if (!xlib_onscreen->is_foreign_xwin) + { + int x, y; + + if (configure_event->send_event) + { + x = configure_event->x; + y = configure_event->y; + } + else + { + Window child; + XTranslateCoordinates (configure_event->display, + configure_event->window, + DefaultRootWindow (configure_event->display), + 0, 0, &x, &y, &child); + } + + xlib_onscreen->x = x; + xlib_onscreen->y = y; + + update_output (onscreen); + } } static CoglFilterReturn @@ -221,9 +274,7 @@ glx_event_filter_cb (XEvent *xevent, void *data) if (xevent->type == ConfigureNotify) { notify_resize (context, - xevent->xconfigure.window, - xevent->xconfigure.width, - xevent->xconfigure.height); + &xevent->xconfigure); /* we let ConfigureNotify pass through */ return COGL_FILTER_CONTINUE; @@ -259,6 +310,38 @@ _cogl_winsys_renderer_disconnect (CoglRenderer *renderer) g_slice_free (CoglGLXRenderer, renderer->winsys); } +static gboolean +update_all_outputs (CoglRenderer *renderer) +{ + GList *l; + + _COGL_GET_CONTEXT (context, FALSE); + + if (context->display == NULL) /* during connection */ + return FALSE; + + if (context->display->renderer != renderer) + return FALSE; + + for (l = context->framebuffers; l; l = l->next) + { + CoglFramebuffer *framebuffer = l->data; + + if (framebuffer->type != COGL_FRAMEBUFFER_TYPE_ONSCREEN) + continue; + + update_output (COGL_ONSCREEN (framebuffer)); + } + + return TRUE; +} + +static void +_cogl_winsys_renderer_outputs_changed (CoglRenderer *renderer) +{ + update_all_outputs (renderer); +} + static CoglBool resolve_core_glx_functions (CoglRenderer *renderer, GError **error) @@ -1023,6 +1106,12 @@ _cogl_winsys_onscreen_deinit (CoglOnscreen *onscreen) if (glx_onscreen == NULL) return; + if (xlib_onscreen->output != NULL) + { + cogl_object_unref (xlib_onscreen->output); + xlib_onscreen->output = NULL; + } + _cogl_xlib_renderer_trap_errors (context->display->renderer, &old_state); if (glx_onscreen->glxwin != None) @@ -2126,6 +2215,7 @@ static CoglWinsysVtable _cogl_winsys_vtable = .renderer_get_proc_address = _cogl_winsys_renderer_get_proc_address, .renderer_connect = _cogl_winsys_renderer_connect, .renderer_disconnect = _cogl_winsys_renderer_disconnect, + .renderer_outputs_changed = _cogl_winsys_renderer_outputs_changed, .display_setup = _cogl_winsys_display_setup, .display_destroy = _cogl_winsys_display_destroy, .context_init = _cogl_winsys_context_init, diff --git a/cogl/winsys/cogl-winsys-private.h b/cogl/winsys/cogl-winsys-private.h index 3262d2f..1ca37e5 100644 --- a/cogl/winsys/cogl-winsys-private.h +++ b/cogl/winsys/cogl-winsys-private.h @@ -83,6 +83,9 @@ typedef struct _CoglWinsysVtable void (*renderer_disconnect) (CoglRenderer *renderer); + void + (*renderer_outputs_changed) (CoglRenderer *renderer); + CoglBool (*display_setup) (CoglDisplay *display, GError **error); diff --git a/configure.ac b/configure.ac index 7f55462..6dae920 100644 --- a/configure.ac +++ b/configure.ac @@ -90,6 +90,7 @@ m4_define([uprof_req_version], [0.3]) m4_define([gtk_doc_req_version], [1.13]) m4_define([xfixes_req_version], [3]) m4_define([xcomposite_req_version], [0.4]) +m4_define([xrandr_req_version], [1.2]) m4_define([cairo_req_version], [1.10]) dnl These variables get copied into the generated README @@ -983,7 +984,7 @@ dnl Check X11 dependencies if required dnl ======================================================== AS_IF([test "x$NEED_XLIB" = "xyes"], [ - X11_MODULES="x11 xext xfixes >= xfixes_req_version xdamage xcomposite >= xcomposite_req_version" + X11_MODULES="x11 xext xfixes >= xfixes_req_version xdamage xcomposite >= xcomposite_req_version xrandr >= xrandr_req_version" PKG_CHECK_MODULES(DUMMY, [$X11_MODULES], [COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES $X11_MODULES"]) SUPPORT_X11=yes -- 1.7.12.1 From otaylor@redhat.com Tue Nov 27 15:19:35 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id EFEA475199E for ; Tue, 27 Nov 2012 15:19:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.193 X-Spam-Level: X-Spam-Status: No, score=-7.193 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.368, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GL=0.077] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dUDg64xLrDs for ; Tue, 27 Nov 2012 15:19:26 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by menubar.gnome.org (Postfix) with ESMTP id A7BEF751A48 for ; Tue, 27 Nov 2012 15:19:26 +0000 (UTC) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARFJObH013456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 10:19:25 -0500 Received: from lagrange.redhat.com (ovpn-113-141.phx2.redhat.com [10.3.113.141]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARFJ6fw026858; Tue, 27 Nov 2012 10:19:24 -0500 From: otaylor@redhat.com To: clutter-list@gnome.org Subject: [PATCH 2/3] Prefer OML_sync_control over SGI_video_sync when waiting for swap Date: Tue, 27 Nov 2012 10:18:58 -0500 Message-Id: <1354029539-29902-3-git-send-email-otaylor@redhat.com> In-Reply-To: <1354029539-29902-1-git-send-email-otaylor@redhat.com> References: <1354029539-29902-1-git-send-email-otaylor@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: "Owen W. Taylor" X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:19:35 -0000 From: "Owen W. Taylor" When we block waiting for the swap, prefer doing that using glXWaitForMsc() from OML_sync_control because that returns a system time value for the precise time of the swap. --- cogl/winsys/cogl-winsys-glx-feature-functions.h | 23 +++++++++++++++++ cogl/winsys/cogl-winsys-glx.c | 34 ++++++++++++++++++++----- 2 files changed, 50 insertions(+), 7 deletions(-) diff --git a/cogl/winsys/cogl-winsys-glx-feature-functions.h b/cogl/winsys/cogl-winsys-glx-feature-functions.h index 71fd827..837b22b 100644 --- a/cogl/winsys/cogl-winsys-glx-feature-functions.h +++ b/cogl/winsys/cogl-winsys-glx-feature-functions.h @@ -84,6 +84,29 @@ COGL_WINSYS_FEATURE_FUNCTION (int, glXSwapInterval, (int interval)) COGL_WINSYS_FEATURE_END () +COGL_WINSYS_FEATURE_BEGIN (sync_control, + "OML\0", + "sync_control\0", + 0, + 0, + 0) +COGL_WINSYS_FEATURE_FUNCTION (Bool, glXGetSyncValues, + (Display* dpy, + GLXDrawable drawable, + int64_t* ust, + int64_t* msc, + int64_t* sbc)) +COGL_WINSYS_FEATURE_FUNCTION (Bool, glXWaitForMsc, + (Display* dpy, + GLXDrawable drawable, + int64_t target_msc, + int64_t divisor, + int64_t remainder, + int64_t* ust, + int64_t* msc, + int64_t* sbc)) +COGL_WINSYS_FEATURE_END () + COGL_WINSYS_FEATURE_BEGIN (copy_sub_buffer, "MESA\0", "copy_sub_buffer\0", diff --git a/cogl/winsys/cogl-winsys-glx.c b/cogl/winsys/cogl-winsys-glx.c index e7f83ab..4714c9a 100644 --- a/cogl/winsys/cogl-winsys-glx.c +++ b/cogl/winsys/cogl-winsys-glx.c @@ -525,7 +525,8 @@ update_winsys_features (CoglContext *context, GError **error) FALSE); } - if (glx_renderer->pf_glXWaitVideoSync) + if (glx_renderer->pf_glXWaitVideoSync || + glx_renderer->pf_glXWaitForMsc) COGL_FLAGS_SET (context->winsys_features, COGL_WINSYS_FEATURE_VBLANK_WAIT, TRUE); @@ -1224,14 +1225,33 @@ _cogl_winsys_wait_for_vblank (void) glx_renderer = ctx->display->renderer->winsys; - if (glx_renderer->pf_glXGetVideoSync) + if (glx_renderer->pf_glXWaitForMsc || + glx_renderer->pf_glXGetVideoSync) { - uint32_t current_count; - glx_renderer->pf_glXGetVideoSync (¤t_count); - glx_renderer->pf_glXWaitVideoSync (2, - (current_count + 1) % 2, - ¤t_count); + if (glx_renderer->pf_glXWaitForMsc) + { + CoglOnscreenGLX *glx_onscreen = onscreen->winsys; + Drawable drawable = glx_onscreen->glxwin; + int64_t ust; + int64_t msc; + int64_t sbc; + + glx_renderer->pf_glXGetSyncValues (xlib_renderer->xdpy, drawable, + &ust, &msc, &sbc); + glx_renderer->pf_glXWaitForMsc (xlib_renderer->xdpy, drawable, + 0, 2, (msc + 1) % 2, + &ust, &msc, &sbc); + } + else + { + uint32_t current_count; + + glx_renderer->pf_glXGetVideoSync (¤t_count); + glx_renderer->pf_glXWaitVideoSync (2, + (current_count + 1) % 2, + ¤t_count); + } } } -- 1.7.12.1 From otaylor@redhat.com Tue Nov 27 15:19:49 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E1532751A0E for ; Tue, 27 Nov 2012 15:19:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.193 X-Spam-Level: X-Spam-Status: No, score=-7.193 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.368, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_GL=0.077] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTT641qYKvFT for ; Tue, 27 Nov 2012 15:19:28 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by menubar.gnome.org (Postfix) with ESMTP id 90DA6751AD8 for ; Tue, 27 Nov 2012 15:19:28 +0000 (UTC) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARFJQ2P030708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 10:19:26 -0500 Received: from lagrange.redhat.com (ovpn-113-141.phx2.redhat.com [10.3.113.141]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARFJ6fx026858; Tue, 27 Nov 2012 10:19:25 -0500 From: otaylor@redhat.com To: clutter-list@gnome.org Subject: [PATCH 3/3] Add CoglFrameTimings Date: Tue, 27 Nov 2012 10:18:59 -0500 Message-Id: <1354029539-29902-4-git-send-email-otaylor@redhat.com> In-Reply-To: <1354029539-29902-1-git-send-email-otaylor@redhat.com> References: <1354029539-29902-1-git-send-email-otaylor@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: "Owen W. Taylor" X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:19:49 -0000 From: "Owen W. Taylor" Add a CoglFrameTimings object that tracks timing information for frames that are drawn. We track a frame counter and frame timing information for each CoglOnscreen. Frames timing information is deliminated by a new cogl_onscreen_begin_frame() and retrieved using cogl_onscreen_get_frame_timings(). --- cogl/Makefile.am | 3 + cogl/cogl-frame-timings-private.h | 44 +++++++ cogl/cogl-frame-timings.c | 78 ++++++++++++ cogl/cogl-frame-timings.h | 133 ++++++++++++++++++++ cogl/cogl-glx-display-private.h | 1 + cogl/cogl-glx-renderer-private.h | 9 ++ cogl/cogl-onscreen-private.h | 28 +++++ cogl/cogl-onscreen.c | 114 ++++++++++++++++++ cogl/cogl-onscreen.h | 118 ++++++++++++++++++ cogl/cogl-x11-renderer-private.h | 1 + cogl/winsys/cogl-winsys-glx.c | 247 +++++++++++++++++++++++++++++++++++--- 11 files changed, 761 insertions(+), 15 deletions(-) create mode 100644 cogl/cogl-frame-timings-private.h create mode 100644 cogl/cogl-frame-timings.c create mode 100644 cogl/cogl-frame-timings.h diff --git a/cogl/Makefile.am b/cogl/Makefile.am index 022caf5..efa94c4 100644 --- a/cogl/Makefile.am +++ b/cogl/Makefile.am @@ -104,6 +104,7 @@ cogl_experimental_h = \ $(srcdir)/cogl-attribute.h \ $(srcdir)/cogl-primitive.h \ $(srcdir)/cogl-clip-state.h \ + $(srcdir)/cogl-frame-timings.h \ $(srcdir)/cogl-framebuffer.h \ $(srcdir)/cogl-onscreen.h \ $(srcdir)/cogl-output.h \ @@ -342,6 +343,8 @@ cogl_sources_c = \ $(srcdir)/cogl-spans.c \ $(srcdir)/cogl-journal-private.h \ $(srcdir)/cogl-journal.c \ + $(srcdir)/cogl-frame-timings-private.h \ + $(srcdir)/cogl-frame-timings.c \ $(srcdir)/cogl-framebuffer-private.h \ $(srcdir)/cogl-framebuffer.c \ $(srcdir)/cogl-onscreen-private.h \ diff --git a/cogl/cogl-frame-timings-private.h b/cogl/cogl-frame-timings-private.h new file mode 100644 index 0000000..b17cd34 --- /dev/null +++ b/cogl/cogl-frame-timings-private.h @@ -0,0 +1,44 @@ +/* + * Cogl + * + * An object oriented GL/GLES Abstraction/Utility Layer + * + * Copyright (C) 2012 Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see . + * + * + */ + +#ifndef __COGL_FRAME_TIMINGS_PRIVATE_H +#define __COGL_FRAME_TIMINGS_PRIVATE_H + +#include "cogl-frame-timings.h" +#include "cogl-object-private.h" + +struct _CoglFrameTimings +{ + CoglObject _parent; + + int64_t frame_counter; + int64_t frame_time; + int64_t presentation_time; + int64_t refresh_interval; + + guint complete : 1; +}; + +CoglFrameTimings *_cogl_frame_timings_new (void); + +#endif /* __COGL_FRAME_TIMINGS_PRIVATE_H */ diff --git a/cogl/cogl-frame-timings.c b/cogl/cogl-frame-timings.c new file mode 100644 index 0000000..ba8003e --- /dev/null +++ b/cogl/cogl-frame-timings.c @@ -0,0 +1,78 @@ +/* + * Cogl + * + * An object oriented GL/GLES Abstraction/Utility Layer + * + * Copyright (C) 2012 Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see . + * + * + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include "cogl-frame-timings-private.h" + +static void _cogl_frame_timings_free (CoglFrameTimings *frame_timings); + +COGL_OBJECT_DEFINE (FrameTimings, frame_timings); + +CoglFrameTimings * +_cogl_frame_timings_new (void) +{ + CoglFrameTimings *timings; + + timings = g_slice_new0 (CoglFrameTimings); + + return _cogl_frame_timings_object_new (timings); +} + +static void +_cogl_frame_timings_free (CoglFrameTimings *timings) +{ + g_slice_free (CoglFrameTimings, timings); +} + +CoglBool +cogl_frame_timings_get_complete (CoglFrameTimings *timings) +{ + return timings->complete; +} + +gint64 +cogl_frame_timings_get_frame_counter (CoglFrameTimings *timings) +{ + return timings->frame_counter; +} + +gint64 +cogl_frame_timings_get_frame_time (CoglFrameTimings *timings) +{ + return timings->frame_time; +} + +gint64 +cogl_frame_timings_get_presentation_time (CoglFrameTimings *timings) +{ + return timings->presentation_time; +} + +gint64 +cogl_frame_timings_get_refresh_interval (CoglFrameTimings *timings) +{ + return timings->refresh_interval; +} diff --git a/cogl/cogl-frame-timings.h b/cogl/cogl-frame-timings.h new file mode 100644 index 0000000..c00e920 --- /dev/null +++ b/cogl/cogl-frame-timings.h @@ -0,0 +1,133 @@ +/* + * Cogl + * + * An object oriented GL/GLES Abstraction/Utility Layer + * + * Copyright (C) 2012 Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * . + * + * + * + * Authors: + * Owen Taylor + */ +#if !defined(__COGL_H_INSIDE__) && !defined(COGL_COMPILATION) +#error "Only can be included directly." +#endif + +#ifndef __COGL_FRAME_TIMINGS_H +#define __COGL_FRAME_TIMINGS_H + +#include +#include + +G_BEGIN_DECLS + +typedef struct _CoglFrameTimings CoglFrameTimings; +#define COGL_FRAME_TIMINGS(X) ((CoglFrameTimings *)(X)) + +/** + * cogl_is_frame_timings: + * @object: A #CoglObject pointer + * + * Gets whether the given object references a #CoglFrameTimings. + * + * Return value: %TRUE if the object references a #CoglFrameTimings + * and %FALSE otherwise. + * Since: 2.0 + * Stability: unstable + */ +CoglBool +cogl_is_frame_timings (void *object); + +/** + * cogl_frame_timings_get_complete: + * @timings: a #CoglFrameTimings object + * + * Gets whether all information that will potentially be provided for + * the frame has been provided. Once a frame timings object is complete, + * no further changes will be made to it. + * + * Return value: whether the frame timings object is complete. + * Since: 2.0 + * Stability: unstable + */ +CoglBool cogl_frame_timings_get_complete (CoglFrameTimings *timings); + +/** + * cogl_frame_timings_get_frame_counter: + * @timings: a #CoglFrameTimings object + * + * Gets the frame counter for the #CoglOnscreen that corresponds + * to this frame. + * + * Return value: The frame counter value + * Since: 2.0 + * Stability: unstable + */ +int64_t cogl_frame_timings_get_frame_counter (CoglFrameTimings *timings); + +/** + * cogl_frame_timings_get_frame_time: + * @timings: a #CoglFrameTimings object + * + * Gets the time used for creating content for the frame. This + * is determined by the time passed to cogl_onscreen_begin_frame(), + * and will typically be the current time when rendering started + * for the frame. + * + * Return value: the time used for coreating content for the frame, + * in the timescale of g_get_monotonic_time(). + * Since: 2.0 + * Stability: unstable + */ +int64_t cogl_frame_timings_get_frame_time (CoglFrameTimings *timings); + +/** + * cogl_frame_timings_get_presentation_time: + * @timings: a #CoglFrameTimings object + * + * Gets the presentation time for the frame. This is the time at which + * the frame became visible to the user. + * + * Return value: the presentation time for the frame, in + * the timescale of g_get_monotonic_time(). + * Since: 2.0 + * Stability: unstable + */ +int64_t cogl_frame_timings_get_presentation_time (CoglFrameTimings *timings); + +/** + * cogl_frame_timings_get_refresh_interval: + * @timings: a #CoglFrameTimings object + * + * Gets the refresh interval for the output that the frame was on at the + * time the frame was presented. This is the number of microseconds between + * refreshes of the screen, and is equal to 1000000 / refresh_rate. + * + * Return value: the refresh interval, in microsecoonds. + * . + * Since: 2.0 + * Stability: unstable + */ +int64_t cogl_frame_timings_get_refresh_interval (CoglFrameTimings *timings); + +G_END_DECLS + +#endif /* __COGL_FRAME_TIMINGS_H */ + + + diff --git a/cogl/cogl-glx-display-private.h b/cogl/cogl-glx-display-private.h index 1ffcd32..cb0fd0d 100644 --- a/cogl/cogl-glx-display-private.h +++ b/cogl/cogl-glx-display-private.h @@ -52,6 +52,7 @@ typedef struct _CoglGLXDisplay Window dummy_xwin; CoglBool pending_swap_notify; CoglBool pending_resize_notify; + CoglBool pending_frame_timings_notify; } CoglGLXDisplay; #endif /* __COGL_DISPLAY_GLX_PRIVATE_H */ diff --git a/cogl/cogl-glx-renderer-private.h b/cogl/cogl-glx-renderer-private.h index 4415ea5..ec9fb66 100644 --- a/cogl/cogl-glx-renderer-private.h +++ b/cogl/cogl-glx-renderer-private.h @@ -42,6 +42,15 @@ typedef struct _CoglGLXRenderer /* Vblank stuff */ int dri_fd; + /* enumeration with relatioship between OML_sync_control + * UST (unadjusted-system-time) and the system clock */ + enum { + COGL_GLX_UST_IS_UNKNOWN, + COGL_GLX_UST_IS_GETTIMEOFDAY, + COGL_GLX_UST_IS_MONOTONIC_TIME, + COGL_GLX_UST_IS_OTHER + } ust_type; + /* GModule pointing to libGL which we use to get glX functions out of */ GModule *libgl_module; diff --git a/cogl/cogl-onscreen-private.h b/cogl/cogl-onscreen-private.h index 06bdd4d..8c35f30 100644 --- a/cogl/cogl-onscreen-private.h +++ b/cogl/cogl-onscreen-private.h @@ -33,6 +33,8 @@ #include #endif +#define COGL_ONSCREEN_MAX_FRAME_TIMINGS 16 + typedef struct _CoglSwapBuffersNotifyEntry CoglSwapBuffersNotifyEntry; COGL_TAILQ_HEAD (CoglSwapBuffersNotifyList, CoglSwapBuffersNotifyEntry); @@ -59,6 +61,19 @@ struct _CoglResizeNotifyEntry unsigned int id; }; +typedef struct _CoglFrameTimingsCallbackEntry CoglFrameTimingsCallbackEntry; + +COGL_TAILQ_HEAD (CoglFrameTimingsCallbackList, CoglFrameTimingsCallbackEntry); + +struct _CoglFrameTimingsCallbackEntry +{ + COGL_TAILQ_ENTRY (CoglFrameTimingsCallbackEntry) list_node; + + CoglFrameTimingsCallback callback; + void *user_data; + unsigned int id; +}; + struct _CoglOnscreen { CoglFramebuffer _parent; @@ -80,6 +95,16 @@ struct _CoglOnscreen CoglBool resizable; CoglResizeNotifyList resize_callbacks; + CoglFrameTimingsCallbackList frame_timings_callbacks; + + int64_t frame_counter; + int64_t swap_frame_counter; /* frame counter at last all to + * cogl_onscreen_swap_region() or + * cogl_onscreen_swap_buffers() */ + CoglFrameTimings *frame_timings[COGL_ONSCREEN_MAX_FRAME_TIMINGS]; + int current_frame_timings; + int n_frame_timings; + void *winsys; }; @@ -96,4 +121,7 @@ _cogl_onscreen_notify_swap_buffers (CoglOnscreen *onscreen); void _cogl_onscreen_notify_resize (CoglOnscreen *onscreen); +void +_cogl_onscreen_notify_frame_timings (CoglOnscreen *onscreen); + #endif /* __COGL_ONSCREEN_PRIVATE_H */ diff --git a/cogl/cogl-onscreen.c b/cogl/cogl-onscreen.c index 4aaa5de..39ffa8d 100644 --- a/cogl/cogl-onscreen.c +++ b/cogl/cogl-onscreen.c @@ -27,6 +27,7 @@ #include "cogl-util.h" #include "cogl-onscreen-private.h" +#include "cogl-frame-timings-private.h" #include "cogl-framebuffer-private.h" #include "cogl-onscreen-template-private.h" #include "cogl-context-private.h" @@ -35,6 +36,8 @@ static void _cogl_onscreen_free (CoglOnscreen *onscreen); +static void cogl_onscreen_before_swap (CoglOnscreen *onscreen); + COGL_OBJECT_DEFINE_WITH_CODE (Onscreen, onscreen, _cogl_onscreen_class.virt_unref = _cogl_framebuffer_unref); @@ -47,6 +50,7 @@ _cogl_onscreen_init_from_template (CoglOnscreen *onscreen, COGL_TAILQ_INIT (&onscreen->swap_callbacks); COGL_TAILQ_INIT (&onscreen->resize_callbacks); + COGL_TAILQ_INIT (&onscreen->frame_timings_callbacks); framebuffer->config = onscreen_template->config; cogl_object_ref (framebuffer->config.swap_chain); @@ -75,6 +79,9 @@ _cogl_onscreen_new (void) COGL_FRAMEBUFFER (onscreen)->allocated = TRUE; + onscreen->frame_counter = -1; + onscreen->current_frame_timings = COGL_ONSCREEN_MAX_FRAME_TIMINGS - 1; + /* XXX: Note we don't initialize onscreen->winsys in this case. */ return _cogl_onscreen_object_new (onscreen); @@ -149,6 +156,8 @@ cogl_onscreen_swap_buffers (CoglOnscreen *onscreen) _COGL_RETURN_IF_FAIL (framebuffer->type == COGL_FRAMEBUFFER_TYPE_ONSCREEN); + cogl_onscreen_before_swap (onscreen); + /* FIXME: we shouldn't need to flush *all* journals here! */ cogl_flush (); winsys = _cogl_framebuffer_get_winsys (framebuffer); @@ -169,6 +178,8 @@ cogl_onscreen_swap_region (CoglOnscreen *onscreen, _COGL_RETURN_IF_FAIL (framebuffer->type == COGL_FRAMEBUFFER_TYPE_ONSCREEN); + cogl_onscreen_before_swap (onscreen); + /* FIXME: we shouldn't need to flush *all* journals here! */ cogl_flush (); @@ -462,3 +473,106 @@ cogl_onscreen_remove_resize_handler (CoglOnscreen *onscreen, } } +int64_t +cogl_onscreen_get_frame_counter (CoglOnscreen *onscreen) +{ + return onscreen->frame_counter; +} + +void +cogl_onscreen_begin_frame (CoglOnscreen *onscreen, + gint64 frame_time) +{ + onscreen->frame_counter++; + onscreen->current_frame_timings = (onscreen->current_frame_timings + 1) % COGL_ONSCREEN_MAX_FRAME_TIMINGS; + + if (onscreen->n_frame_timings < COGL_ONSCREEN_MAX_FRAME_TIMINGS) + onscreen->n_frame_timings++; + else + cogl_object_unref (onscreen->frame_timings[onscreen->current_frame_timings]); + + onscreen->frame_timings[onscreen->current_frame_timings] = _cogl_frame_timings_new (); + onscreen->frame_timings[onscreen->current_frame_timings]->frame_counter = onscreen->frame_counter; + onscreen->frame_timings[onscreen->current_frame_timings]->frame_time = frame_time; +} + +static void +cogl_onscreen_before_swap (CoglOnscreen *onscreen) +{ + if (onscreen->swap_frame_counter == onscreen->frame_counter) + cogl_onscreen_begin_frame (onscreen, 0); + + onscreen->swap_frame_counter = onscreen->frame_counter; +} + +int64_t +cogl_onscreen_get_frame_history_start (CoglOnscreen *onscreen) +{ + return onscreen->frame_counter - onscreen->n_frame_timings; +} + +CoglFrameTimings * +cogl_onscreen_get_frame_timings (CoglOnscreen *onscreen, + int64_t frame_counter) +{ + int pos; + + if (frame_counter > onscreen->frame_counter) + return NULL; + + if (frame_counter <= onscreen->frame_counter - onscreen->n_frame_timings) + return NULL; + + pos = ((onscreen->current_frame_timings - + (onscreen->frame_counter - frame_counter) + COGL_ONSCREEN_MAX_FRAME_TIMINGS) + % COGL_ONSCREEN_MAX_FRAME_TIMINGS); + + return onscreen->frame_timings[pos]; +} + +unsigned int +cogl_onscreen_add_frame_timings_callback (CoglOnscreen *onscreen, + CoglFrameTimingsCallback callback, + void *user_data) +{ + CoglFrameTimingsCallbackEntry *entry = g_slice_new (CoglFrameTimingsCallbackEntry); + static int next_resize_callback_id = 0; + + entry->callback = callback; + entry->user_data = user_data; + entry->id = next_resize_callback_id++; + + COGL_TAILQ_INSERT_TAIL (&onscreen->frame_timings_callbacks, entry, list_node); + + return entry->id; +} + +void +cogl_onscreen_remove_frame_timings_callback (CoglOnscreen *onscreen, + unsigned int id) +{ + CoglFrameTimingsCallbackEntry *entry; + + COGL_TAILQ_FOREACH (entry, &onscreen->frame_timings_callbacks, list_node) + { + if (entry->id == id) + { + COGL_TAILQ_REMOVE (&onscreen->frame_timings_callbacks, entry, list_node); + g_slice_free (CoglFrameTimingsCallbackEntry, entry); + break; + } + } +} + +void +_cogl_onscreen_notify_frame_timings (CoglOnscreen *onscreen) +{ + CoglFrameTimingsCallbackEntry *entry, *tmp; + + COGL_TAILQ_FOREACH_SAFE (entry, + &onscreen->frame_timings_callbacks, + list_node, + tmp) + entry->callback (onscreen, entry->user_data); +} + diff --git a/cogl/cogl-onscreen.h b/cogl/cogl-onscreen.h index c4c4dfd..3338991 100644 --- a/cogl/cogl-onscreen.h +++ b/cogl/cogl-onscreen.h @@ -34,6 +34,7 @@ #include #include +#include #include G_BEGIN_DECLS @@ -532,6 +533,123 @@ cogl_onscreen_remove_resize_handler (CoglOnscreen *onscreen, CoglBool cogl_is_onscreen (void *object); +/** + * cogl_onscreen_get_frame_counter: + * + * Gets the value of the framebuffers frame counter. This is + * a counter that increases by one each time + * cogl_onscreen_swap_buffers() or cogl_onscreen_swap_region() + * is called. + * + * Return value: the current frame counter value + * Since: 2.0 + */ +int64_t +cogl_onscreen_get_frame_counter (CoglOnscreen *onscreen); + +/** + * cogl_onscreen_begin_frame: + * @onscreen: a #CoglOnscreen framebuffer + * @frame_time: the time that should be used for creating + * content for this frame. + * + * Marks the beginning of a frame. This increases the frame + * counter value and creates a new #CoglFrameTimings objeect. + * + * Since: 2.0 + */ +void +cogl_onscreen_begin_frame (CoglOnscreen *onscreen, + gint64 frame_time); + +/** + * cogl_onscreen_get_frame_history_start: + * @onscreen: a #CoglOnscreen framebuffer + * + * Gets the frame counter for the oldest #CoglFrameTiming that is + * being kept in the history. cogl_onscreen_get_frame_timings() will + * always return %NULl for any frame counter before this. + * + * Return value: the frame counter for the oldest #CoglFrameTimings + * in the history. + * Since: 2.0 + */ +int64_t +cogl_onscreen_get_frame_history_start (CoglOnscreen *onscreen); + + +/** + * cogl_onscreen_get_frame_timings: + * @onscreen: A #CoglOnscreen framebuffer + * @frame_counter: the value of cogl_onscreen_get_frame_counter() + * when the frame finished drawing. + * + * Gets frame timing information for a particular frame. + * + * Return value: a #CoglFrameTiming object, or %NULL if frame timing + * information is not available for the given frame. + * Since: 2.0 + */ +CoglFrameTimings * +cogl_onscreen_get_frame_timings (CoglOnscreen *onscreen, + int64_t frame_counter); + +/** + * CoglFrameTimingsCallback: + * @onscreen: A #CoglOnscreen framebuffer that has updated timing information + * @user_data: The private passed to + * cogl_onscreen_add_frame_timings_callback() + * + * Is a callback type used with the + * cogl_onscreen_add_frame_timings_callback() allowing applications to be + * notified whenever new frame timings information is available + * via cogl_onscreen_get_frame_timings(). + * + * A frame timings callback will only ever be called while dispatching + * Cogl events from the system mainloop; so for example during + * cogl_poll_dispatch(). This is so that callbacks shouldn't occur + * while an application might have arbitrary locks held for + * example. + * + * Since: 2.0 + */ +typedef void (*CoglFrameTimingsCallback) (CoglOnscreen *onscreen, + void *user_data); + +/** + * cogl_onscreen_add_frame_timings_callback: + * @onscreen: A #CoglOnscreen framebuffer + * @callback: A callback function to call when new frame timings information is available + * @user_data: A private pointer to be passed to @callback + * + * Installs a @callback function that should be called whenever new data + * is available via cogl_onscreen_get_frame_timings(). + * + * Return value: a unique identifier that can be used to remove to remove + * the callback later. + * Since: 2.0 + * Stability: unstable + */ +unsigned int +cogl_onscreen_add_frame_timings_callback (CoglOnscreen *onscreen, + CoglFrameTimingsCallback callback, + void *user_data); + +/** + * cogl_onscreen_remove_frame_timings_callback: + * @onscreen: A #CoglOnscreen framebuffer + * @id: An identifier returned from cogl_onscreen_add_frame_timings_callback() + * + * Removes a callback that was previously registered + * using cogl_onscreen_add_frame_timings_callback(). + * + * Since: 1.10 + * Stability: unstable + */ +void +cogl_onscreen_remove_frame_timings_callback (CoglOnscreen *onscreen, + unsigned int id); + G_END_DECLS #endif /* __COGL_ONSCREEN_H */ diff --git a/cogl/cogl-x11-renderer-private.h b/cogl/cogl-x11-renderer-private.h index 54a5639..0b70012 100644 --- a/cogl/cogl-x11-renderer-private.h +++ b/cogl/cogl-x11-renderer-private.h @@ -27,6 +27,7 @@ typedef struct _CoglX11Renderer { int damage_base; + int randr_base; } CoglX11Renderer; #endif /* __COGL_RENDERER_X11_PRIVATE_H */ diff --git a/cogl/winsys/cogl-winsys-glx.c b/cogl/winsys/cogl-winsys-glx.c index 4714c9a..669a6a4 100644 --- a/cogl/winsys/cogl-winsys-glx.c +++ b/cogl/winsys/cogl-winsys-glx.c @@ -42,6 +42,7 @@ #include "cogl-texture-2d-private.h" #include "cogl-texture-rectangle-private.h" #include "cogl-pipeline-opengl-private.h" +#include "cogl-frame-timings-private.h" #include "cogl-framebuffer-private.h" #include "cogl-onscreen-private.h" #include "cogl-swap-chain-private.h" @@ -52,6 +53,7 @@ #include #include #include +#include #include #include @@ -83,6 +85,7 @@ typedef struct _CoglOnscreenGLX uint32_t last_swap_vsync_counter; CoglBool pending_swap_notify; CoglBool pending_resize_notify; + CoglBool pending_frame_timings_notify; } CoglOnscreenGLX; typedef struct _CoglTexturePixmapGLX @@ -167,16 +170,134 @@ find_onscreen_for_xid (CoglContext *context, uint32_t xid) } static void -notify_swap_buffers (CoglContext *context, GLXDrawable drawable) +ensure_ust_type (CoglRenderer *renderer, + GLXDrawable drawable) { - CoglOnscreen *onscreen = find_onscreen_for_xid (context, (uint32_t)drawable); + CoglGLXRenderer *glx_renderer = renderer->winsys; + CoglXlibRenderer *xlib_renderer = _cogl_xlib_renderer_get_data (renderer); + int64_t ust; + int64_t msc; + int64_t sbc; + struct timeval tv; + gint64 current_system_time; + gint64 current_monotonic_time; + + if (glx_renderer->ust_type != COGL_GLX_UST_IS_UNKNOWN) + return; + + glx_renderer->ust_type = COGL_GLX_UST_IS_OTHER; + + if (glx_renderer->pf_glXGetSyncValues == NULL) + goto out; + + if (!glx_renderer->pf_glXGetSyncValues (xlib_renderer->xdpy, drawable, + &ust, &msc, &sbc)) + goto out; + + /* This is the method that Xorg uses currently */ + gettimeofday(&tv, NULL); + current_system_time = (tv.tv_sec * G_GINT64_CONSTANT (1000000)) + tv.tv_usec; + + if (current_system_time > ust - 1000000 && current_system_time < ust + 1000000) + { + glx_renderer->ust_type = COGL_GLX_UST_IS_GETTIMEOFDAY; + goto out; + } + + /* This is the method that would make sense for a GL implementation to use - + * clock_gettime (CLOCK_MONOTONIC, &ts) */ + current_monotonic_time = g_get_monotonic_time (); + if (current_monotonic_time > ust - 1000000 && current_monotonic_time < ust + 1000000) + { + glx_renderer->ust_type = COGL_GLX_UST_IS_MONOTONIC_TIME; + goto out; + } + + out: + COGL_NOTE (WINSYS, "Classified OML system time as: %s", + glx_renderer->ust_type == COGL_GLX_UST_IS_GETTIMEOFDAY ? "gettimeofday" : + (glx_renderer->ust_type == COGL_GLX_UST_IS_MONOTONIC_TIME ? "monotonic" : + "other")); + return; +} + +static gint64 +ust_to_monotonic_time (CoglRenderer *renderer, + GLXDrawable drawable, + int64_t ust) +{ + CoglGLXRenderer *glx_renderer = renderer->winsys; + CoglXlibRenderer *xlib_renderer = _cogl_xlib_renderer_get_data (renderer); + + ensure_ust_type (renderer, drawable); + + switch (glx_renderer->ust_type) + { + case COGL_GLX_UST_IS_UNKNOWN: + g_assert_not_reached (); + break; + case COGL_GLX_UST_IS_GETTIMEOFDAY: + { + struct timeval tv; + gint64 current_system_time; + gint64 current_monotonic_time; + + gettimeofday(&tv, NULL); + current_system_time = (tv.tv_sec * G_GINT64_CONSTANT (1000000)) + tv.tv_usec; + current_monotonic_time = g_get_monotonic_time (); + + return ust + current_monotonic_time - current_system_time; + } + case COGL_GLX_UST_IS_MONOTONIC_TIME: + return ust; + case COGL_GLX_UST_IS_OTHER: + { + if (glx_renderer->pf_glXGetSyncValues) + { + gint64 current_monotonic_time; + int64_t ust; + int64_t msc; + int64_t sbc; + + glx_renderer->pf_glXGetSyncValues (xlib_renderer->xdpy, drawable, + &ust, &msc, &sbc); + + current_monotonic_time = g_get_monotonic_time (); + return ust + current_monotonic_time - ust; + } + break; + } + } + + return 0; +} + +static void +set_timings_complete (CoglOnscreen *onscreen) +{ + CoglOnscreenGLX *glx_onscreen = onscreen->winsys; + CoglContext *context = COGL_FRAMEBUFFER (onscreen)->context; + CoglGLXDisplay *glx_display = context->display->winsys; + CoglFrameTimings *timings = cogl_onscreen_get_frame_timings (onscreen, + cogl_onscreen_get_frame_counter (onscreen)); + + timings->complete = TRUE; + + glx_display->pending_frame_timings_notify = TRUE; + glx_onscreen->pending_frame_timings_notify = TRUE; +} + +static void +notify_swap_buffers (CoglContext *context, GLXBufferSwapComplete *swap_event) +{ + CoglOnscreen *onscreen = find_onscreen_for_xid (context, (uint32_t)swap_event->drawable); CoglDisplay *display = context->display; CoglGLXDisplay *glx_display = display->winsys; CoglOnscreenGLX *glx_onscreen; + CoglFrameTimings *timings; if (!onscreen) return; - glx_onscreen = onscreen->winsys; /* We only want to notify that the swap is complete when the @@ -184,6 +305,15 @@ notify_swap_buffers (CoglContext *context, GLXDrawable drawable) notifying we'll set a flag to remember to notify later */ glx_display->pending_swap_notify = TRUE; glx_onscreen->pending_swap_notify = TRUE; + + timings = cogl_onscreen_get_frame_timings (onscreen, + cogl_onscreen_get_frame_counter (onscreen)); + if (swap_event->ust != 0) + timings->presentation_time = ust_to_monotonic_time (context->display->renderer, + glx_onscreen->glxwin, + swap_event->ust); + + set_timings_complete (onscreen); } static void @@ -287,7 +417,7 @@ glx_event_filter_cb (XEvent *xevent, void *data) { GLXBufferSwapComplete *swap_event = (GLXBufferSwapComplete *) xevent; - notify_swap_buffers (context, swap_event->drawable); + notify_swap_buffers (context, swap_event); /* remove SwapComplete events from the queue */ return COGL_FILTER_REMOVE; @@ -1217,17 +1347,32 @@ _cogl_winsys_onscreen_bind (CoglOnscreen *onscreen) } static void -_cogl_winsys_wait_for_vblank (void) +_cogl_winsys_wait_for_gpu (CoglOnscreen *onscreen) { - CoglGLXRenderer *glx_renderer; + CoglFramebuffer *framebuffer = COGL_FRAMEBUFFER (onscreen); + CoglContext *ctx = framebuffer->context; - _COGL_GET_CONTEXT (ctx, NO_RETVAL); + ctx->glFinish (); +} + +static void +_cogl_winsys_wait_for_vblank (CoglOnscreen *onscreen) +{ + CoglFramebuffer *framebuffer = COGL_FRAMEBUFFER (onscreen); + CoglContext *ctx = framebuffer->context; + CoglGLXRenderer *glx_renderer; + CoglXlibRenderer *xlib_renderer; glx_renderer = ctx->display->renderer->winsys; + xlib_renderer = _cogl_xlib_renderer_get_data (ctx->display->renderer); if (glx_renderer->pf_glXWaitForMsc || glx_renderer->pf_glXGetVideoSync) { + CoglFrameTimings *timings; + + timings = cogl_onscreen_get_frame_timings (onscreen, + cogl_onscreen_get_frame_counter (onscreen)); if (glx_renderer->pf_glXWaitForMsc) { @@ -1242,6 +1387,9 @@ _cogl_winsys_wait_for_vblank (void) glx_renderer->pf_glXWaitForMsc (xlib_renderer->xdpy, drawable, 0, 2, (msc + 1) % 2, &ust, &msc, &sbc); + timings->presentation_time = ust_to_monotonic_time (ctx->display->renderer, + drawable, + ust); } else { @@ -1251,6 +1399,7 @@ _cogl_winsys_wait_for_vblank (void) glx_renderer->pf_glXWaitVideoSync (2, (current_count + 1) % 2, ¤t_count); + timings->presentation_time = g_get_monotonic_time (); } } } @@ -1271,6 +1420,19 @@ _cogl_winsys_get_vsync_counter (void) } static void +set_refresh_interval_from_output (CoglOnscreen *onscreen, + CoglOutput *output) +{ + float refresh_rate = cogl_output_get_refresh_rate (output); + if (refresh_rate != 0.0) + { + CoglFrameTimings *timings = cogl_onscreen_get_frame_timings (onscreen, + cogl_onscreen_get_frame_counter (onscreen)); + timings->refresh_interval = (int)(0.5 + (1000000. / refresh_rate)); + } +} + +static void _cogl_winsys_onscreen_swap_region (CoglOnscreen *onscreen, const int *user_rectangles, int n_rectangles) @@ -1287,6 +1449,7 @@ _cogl_winsys_onscreen_swap_region (CoglOnscreen *onscreen, uint32_t end_frame_vsync_counter = 0; CoglBool have_counter; CoglBool can_wait; + int x_min = 0, x_max = 0, y_min = 0, y_max = 0; /* * We assume that glXCopySubBuffer is synchronized which means it won't prevent multiple @@ -1297,6 +1460,7 @@ _cogl_winsys_onscreen_swap_region (CoglOnscreen *onscreen, CoglBool blit_sub_buffer_is_synchronized = _cogl_winsys_has_feature (COGL_WINSYS_FEATURE_SWAP_REGION_SYNCHRONIZED); + int framebuffer_width = cogl_framebuffer_get_width (framebuffer); int framebuffer_height = cogl_framebuffer_get_height (framebuffer); int *rectangles = g_alloca (sizeof (int) * n_rectangles * 4); int i; @@ -1308,7 +1472,24 @@ _cogl_winsys_onscreen_swap_region (CoglOnscreen *onscreen, for (i = 0; i < n_rectangles; i++) { int *rect = &rectangles[4 * i]; + + if (i == 0) + { + x_min = rect[0]; + x_max = rect[0] + rect[2]; + y_min = rect[1]; + y_max = rect[1] + rect[3]; + } + else + { + x_min = MIN (x_min, rect[0]); + x_max = MAX (x_max, rect[0] + rect[2]); + y_min = MIN (y_min, rect[1]); + y_max = MAX (y_max, rect[1] + rect[3]); + } + rect[1] = framebuffer_height - rect[1] - rect[3]; + } _cogl_framebuffer_flush_state (framebuffer, @@ -1362,7 +1543,7 @@ _cogl_winsys_onscreen_swap_region (CoglOnscreen *onscreen, * additional extension so we can report the limited region of * the window damage to X/compositors. */ - context->glFinish (); + _cogl_winsys_wait_for_gpu (onscreen); if (blit_sub_buffer_is_synchronized && have_counter && can_wait) { @@ -1373,10 +1554,10 @@ _cogl_winsys_onscreen_swap_region (CoglOnscreen *onscreen, * any waits if we can see that the video sync count has * already progressed. */ if (glx_onscreen->last_swap_vsync_counter == end_frame_vsync_counter) - _cogl_winsys_wait_for_vblank (); + _cogl_winsys_wait_for_vblank (onscreen); } else if (can_wait) - _cogl_winsys_wait_for_vblank (); + _cogl_winsys_wait_for_vblank (onscreen); if (glx_renderer->pf_glXCopySubBuffer) { @@ -1425,6 +1606,24 @@ _cogl_winsys_onscreen_swap_region (CoglOnscreen *onscreen, */ if (have_counter) glx_onscreen->last_swap_vsync_counter = end_frame_vsync_counter; + + if (!xlib_onscreen->is_foreign_xwin) + { + CoglOutput *output; + + x_min = CLAMP (x_min, 0, framebuffer_width); + x_max = CLAMP (x_max, 0, framebuffer_width); + y_min = CLAMP (y_min, 0, framebuffer_width); + y_max = CLAMP (y_max, 0, framebuffer_height); + + output = _cogl_xlib_renderer_output_for_rectangle (context->display->renderer, + xlib_onscreen->x + x_min, xlib_onscreen->y + y_min, + x_max - x_min, y_max - y_min); + if (output) + set_refresh_interval_from_output (onscreen, output); + } + + set_timings_complete (onscreen); } static void @@ -1484,16 +1683,16 @@ _cogl_winsys_onscreen_swap_buffers (CoglOnscreen *onscreen) * obviously does not happen when we use _GLX_SWAP and let * the driver do the right thing */ - context->glFinish (); + _cogl_winsys_wait_for_gpu (onscreen); if (have_counter && can_wait) { if (glx_onscreen->last_swap_vsync_counter == end_frame_vsync_counter) - _cogl_winsys_wait_for_vblank (); + _cogl_winsys_wait_for_vblank (onscreen); } else if (can_wait) - _cogl_winsys_wait_for_vblank (); + _cogl_winsys_wait_for_vblank (onscreen); } } else @@ -1503,6 +1702,13 @@ _cogl_winsys_onscreen_swap_buffers (CoglOnscreen *onscreen) if (have_counter) glx_onscreen->last_swap_vsync_counter = _cogl_winsys_get_vsync_counter (); + + if (xlib_onscreen->output) + set_refresh_interval_from_output (onscreen, xlib_onscreen->output); + + if (!(glx_renderer->pf_glXSwapInterval && + _cogl_winsys_has_feature (COGL_WINSYS_FEATURE_VBLANK_WAIT))) + set_timings_complete (onscreen); } static uint32_t @@ -2174,7 +2380,9 @@ _cogl_winsys_poll_get_info (CoglContext *context, /* If we've already got a pending swap notify then we'll dispatch immediately */ - if (glx_display->pending_swap_notify || glx_display->pending_resize_notify) + if (glx_display->pending_swap_notify || + glx_display->pending_resize_notify || + glx_display->pending_frame_timings_notify) *timeout = 0; } @@ -2200,6 +2408,12 @@ flush_pending_notifications_cb (void *data, _cogl_onscreen_notify_resize (onscreen); glx_onscreen->pending_resize_notify = FALSE; } + + if (glx_onscreen->pending_frame_timings_notify) + { + _cogl_onscreen_notify_frame_timings (onscreen); + glx_onscreen->pending_frame_timings_notify = FALSE; + } } } @@ -2215,13 +2429,16 @@ _cogl_winsys_poll_dispatch (CoglContext *context, poll_fds, n_poll_fds); - if (glx_display->pending_swap_notify || glx_display->pending_resize_notify) + if (glx_display->pending_swap_notify || + glx_display->pending_resize_notify || + glx_display->pending_frame_timings_notify) { g_list_foreach (context->framebuffers, flush_pending_notifications_cb, NULL); glx_display->pending_swap_notify = FALSE; glx_display->pending_resize_notify = FALSE; + glx_display->pending_frame_timings_notify = FALSE; } } -- 1.7.12.1 From otaylor@redhat.com Tue Nov 27 15:53:50 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 9F20575199E for ; Tue, 27 Nov 2012 15:53:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.27 X-Spam-Level: X-Spam-Status: No, score=-7.27 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.368, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQNouWPRjPSj for ; Tue, 27 Nov 2012 15:53:37 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by menubar.gnome.org (Postfix) with ESMTP id B4A22751AED for ; Tue, 27 Nov 2012 15:53:37 +0000 (UTC) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARFraMf009490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Nov 2012 10:53:36 -0500 Received: from lagrange.redhat.com (ovpn-113-141.phx2.redhat.com [10.3.113.141]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARFrZXC013478 for ; Tue, 27 Nov 2012 10:53:35 -0500 From: otaylor@redhat.com To: clutter-list@gnome.org Subject: Clutter patches for frame synchronization Date: Tue, 27 Nov 2012 10:53:29 -0500 Message-Id: <1354031611-30960-1-git-send-email-otaylor@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:53:50 -0000 Here are a couple of Clutter patches that go along with the Cogl patch set I just posted. The need for clutter_stage_set_sync_delay() is a little bit obscure - what it's handling is that if you have an application with a strict need for predictable latency running under Mutter, you don't want to get different behaviors if: a) it draws and the Clutter master clock within Mutter is idle. b) it draws and the Clutter master clock is waiting for the last frame to be processed before it draws again. (Because somoe other application did an update, say.) Currently Clutter draws immediately immediately in case a) giving a latency of 0-16ms, but in case b) you get a latency of 16-32ms. This really messes up trying to get frame accurate display of a 24 or 30fps video if there is anything else going on on the system - not because of loading but because of switching between the two cases. But just adding an alternate mode is not enough because if you have an app that is limited by rendering (instead of one that is limited by the number of frames it has to display) adding a delay in the compositor is fatal - it means that the GPU/CPU stay in power saving mode and you get 30fps when you could get 60fps. So clutter_stage_skip_sync_delay() is added as well for when Mutter gets an update from such a client. (See the Mutter wip/frame-synchronization branch for full details.) From otaylor@redhat.com Tue Nov 27 15:54:08 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 1A099751B32 for ; Tue, 27 Nov 2012 15:53:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.193 X-Spam-Level: X-Spam-Status: No, score=-7.193 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.368, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TW_VB=0.077] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6SZPnYQAiuG for ; Tue, 27 Nov 2012 15:53:41 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by menubar.gnome.org (Postfix) with ESMTP id 65A99751B01 for ; Tue, 27 Nov 2012 15:53:41 +0000 (UTC) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARFrdK6024948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 10:53:39 -0500 Received: from lagrange.redhat.com (ovpn-113-141.phx2.redhat.com [10.3.113.141]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARFrZXD013478; Tue, 27 Nov 2012 10:53:38 -0500 From: otaylor@redhat.com To: clutter-list@gnome.org Subject: [PATCH 1/2] Add clutter_stage_set_sync_delay() Date: Tue, 27 Nov 2012 10:53:30 -0500 Message-Id: <1354031611-30960-2-git-send-email-otaylor@redhat.com> In-Reply-To: <1354031611-30960-1-git-send-email-otaylor@redhat.com> References: <1354031611-30960-1-git-send-email-otaylor@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: "Owen W. Taylor" X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:54:08 -0000 From: "Owen W. Taylor" New experimental API is added to allow changing the way that redraws are timed for a stage to include a "sync delay" - a period after the vertical blanking period where Clutter simply waits for updates. In detail, the algorithm is that when the master clock is restarted after drawing a frame (in the case where there are timelines running) or started fresh in response to a queued redraw or relayout, the start is scheduled at the next sync point (sync_delay ms after the predicted vblank period) rather than done immediately. --- clutter/clutter-master-clock.c | 153 ++++++++++++++++++++++++++++---------- clutter/clutter-stage-private.h | 4 +- clutter/clutter-stage-window.c | 43 ++++++++++- clutter/clutter-stage-window.h | 10 ++- clutter/clutter-stage.c | 98 ++++++++++++++++++++++-- clutter/clutter-stage.h | 6 ++ clutter/cogl/clutter-stage-cogl.c | 81 +++++++++++++++++++- clutter/cogl/clutter-stage-cogl.h | 1 + 8 files changed, 340 insertions(+), 56 deletions(-) diff --git a/clutter/clutter-master-clock.c b/clutter/clutter-master-clock.c index 32655ee..acd5dc8 100644 --- a/clutter/clutter-master-clock.c +++ b/clutter/clutter-master-clock.c @@ -139,24 +139,9 @@ master_clock_is_running (ClutterMasterClock *master_clock) { ClutterStageManager *stage_manager = clutter_stage_manager_get_default (); const GSList *stages, *l; - gboolean stage_free = FALSE; stages = clutter_stage_manager_peek_stages (stage_manager); - /* If all of the stages are busy waiting for a swap-buffers to complete - * then we stop the master clock... */ - for (l = stages; l != NULL; l = l->next) - { - if (_clutter_stage_get_pending_swaps (l->data) == 0) - { - stage_free = TRUE; - break; - } - } - - if (!stage_free) - return FALSE; - if (master_clock->timelines) return TRUE; @@ -176,6 +161,103 @@ master_clock_is_running (ClutterMasterClock *master_clock) return FALSE; } +static gint +master_clock_get_swap_wait_time (ClutterMasterClock *master_clock) +{ + ClutterStageManager *stage_manager = clutter_stage_manager_get_default (); + const GSList *stages, *l; + gint64 min_update_time = -1; + + stages = clutter_stage_manager_peek_stages (stage_manager); + + for (l = stages; l != NULL; l = l->next) + { + gint64 update_time = _clutter_stage_get_update_time (l->data); + if (min_update_time == -1 || + (update_time != -1 && update_time < min_update_time)) + min_update_time = update_time; + } + + if (min_update_time == -1) + { + return -1; + } + else + { + gint64 now = g_source_get_time (master_clock->source); + if (min_update_time < now) + { + return 0; + } + else + { + gint64 delay_us = min_update_time - now; + return (delay_us + 999) / 1000; + } + } +} + +static void +master_clock_schedule_stage_updates (ClutterMasterClock *master_clock) +{ + ClutterStageManager *stage_manager = clutter_stage_manager_get_default (); + const GSList *stages, *l; + + stages = clutter_stage_manager_peek_stages (stage_manager); + + for (l = stages; l != NULL; l = l->next) + _clutter_stage_schedule_update (l->data); +} + +static GSList * +master_clock_list_ready_stages (ClutterMasterClock *master_clock) +{ + ClutterStageManager *stage_manager = clutter_stage_manager_get_default (); + const GSList *stages, *l; + GSList *result; + + stages = clutter_stage_manager_peek_stages (stage_manager); + + result = NULL; + for (l = stages; l != NULL; l = l->next) + { + gint64 update_time = _clutter_stage_get_update_time (l->data); + + /* If a stage has a swap-buffers pending we don't want to draw to it + * in case the driver may block the CPU while it waits for the next + * backbuffer to become available. + * + * TODO: We should be able to identify if we are running triple or N + * buffered and in these cases we can still draw if there is 1 swap + * pending so we can hopefully always be ready to swap for the next + * vblank and really match the vsync frequency. + */ + if (update_time != -1 && update_time <= master_clock->cur_tick) + result = g_slist_prepend (result, g_object_ref (l->data)); + } + + return g_slist_reverse (result); +} + +static void +master_clock_reschedule_stage_updates (ClutterMasterClock *master_clock, + GSList *stages) +{ + const GSList *l; + + for (l = stages; l != NULL; l = l->next) + { + /* Clear the old update time */ + _clutter_stage_clear_update_time (l->data); + + /* And if there is still work to be done, schedule a new one */ + if (master_clock->timelines || + _clutter_stage_has_queued_events (l->data) || + _clutter_stage_needs_update (l->data)) + _clutter_stage_schedule_update (l->data); + } +} + /* * master_clock_next_frame_delay: * @master_clock: a #ClutterMasterClock @@ -189,10 +271,17 @@ static gint master_clock_next_frame_delay (ClutterMasterClock *master_clock) { gint64 now, next; + gint swap_delay; if (!master_clock_is_running (master_clock)) return -1; + /* If all of the stages are busy waiting for a swap-buffers to complete + * then we wait for one to be ready.. */ + swap_delay = master_clock_get_swap_wait_time (master_clock); + if (swap_delay != 0) + return swap_delay; + /* When we have sync-to-vblank, we count on swap-buffer requests (or * swap-buffer-complete events if supported in the backend) to throttle our * frame rate so no additional delay is needed to start the next frame. @@ -274,14 +363,7 @@ master_clock_process_events (ClutterMasterClock *master_clock, /* Process queued events */ for (l = stages; l != NULL; l = l->next) - { - /* NB: If a stage is busy waiting for a swap-buffers completion then - * we don't process its events so we can maximize the benefits of - * motion compression, and avoid multiple picks per frame. - */ - if (_clutter_stage_get_pending_swaps (l->data) == 0) - _clutter_stage_process_queued_events (l->data); - } + _clutter_stage_process_queued_events (l->data); CLUTTER_TIMER_STOP (_clutter_uprof_context, master_event_process); @@ -372,19 +454,7 @@ master_clock_update_stages (ClutterMasterClock *master_clock, * is advanced. */ for (l = stages; l != NULL; l = l->next) - { - /* If a stage has a swap-buffers pending we don't want to draw to it - * in case the driver may block the CPU while it waits for the next - * backbuffer to become available. - * - * TODO: We should be able to identify if we are running triple or N - * buffered and in these cases we can still draw if there is 1 swap - * pending so we can hopefully always be ready to swap for the next - * vblank and really match the vsync frequency. - */ - if (_clutter_stage_get_pending_swaps (l->data) == 0) - stages_updated |= _clutter_stage_do_update (l->data); - } + stages_updated |= _clutter_stage_do_update (l->data); _clutter_run_repaint_functions (CLUTTER_REPAINT_FLAGS_POST_PAINT); @@ -474,7 +544,6 @@ clutter_clock_dispatch (GSource *source, { ClutterClockSource *clock_source = (ClutterClockSource *) source; ClutterMasterClock *master_clock = clock_source->master_clock; - ClutterStageManager *stage_manager = clutter_stage_manager_get_default (); gboolean stages_updated = FALSE; GSList *stages; @@ -500,8 +569,7 @@ clutter_clock_dispatch (GSource *source, /* We need to protect ourselves against stages being destroyed during * event handling */ - stages = clutter_stage_manager_list_stages (stage_manager); - g_slist_foreach (stages, (GFunc) g_object_ref, NULL); + stages = master_clock_list_ready_stages (master_clock); master_clock->idle = FALSE; @@ -524,6 +592,8 @@ clutter_clock_dispatch (GSource *source, if (!stages_updated) master_clock->idle = TRUE; + master_clock_reschedule_stage_updates (master_clock, stages); + g_slist_foreach (stages, (GFunc) g_object_unref, NULL); g_slist_free (stages); @@ -617,7 +687,10 @@ _clutter_master_clock_add_timeline (ClutterMasterClock *master_clock, timeline); if (is_first) - _clutter_master_clock_start_running (master_clock); + { + master_clock_schedule_stage_updates (master_clock); + _clutter_master_clock_start_running (master_clock); + } } /* diff --git a/clutter/clutter-stage-private.h b/clutter/clutter-stage-private.h index 89d1dbd..9ccba3f 100644 --- a/clutter/clutter-stage-private.h +++ b/clutter/clutter-stage-private.h @@ -66,7 +66,9 @@ void _clutter_stage_queue_event (ClutterStage *stage, gboolean _clutter_stage_has_queued_events (ClutterStage *stage); void _clutter_stage_process_queued_events (ClutterStage *stage); void _clutter_stage_update_input_devices (ClutterStage *stage); -int _clutter_stage_get_pending_swaps (ClutterStage *stage); +void _clutter_stage_schedule_update (ClutterStage *stage); +gint64 _clutter_stage_get_update_time (ClutterStage *stage); +void _clutter_stage_clear_update_time (ClutterStage *stage); gboolean _clutter_stage_has_full_redraw_queued (ClutterStage *stage); ClutterActor *_clutter_stage_do_pick (ClutterStage *stage, diff --git a/clutter/clutter-stage-window.c b/clutter/clutter-stage-window.c index 3ba3c99..ffa30a1 100644 --- a/clutter/clutter-stage-window.c +++ b/clutter/clutter-stage-window.c @@ -122,21 +122,56 @@ _clutter_stage_window_get_geometry (ClutterStageWindow *window, CLUTTER_STAGE_WINDOW_GET_IFACE (window)->get_geometry (window, geometry); } -int -_clutter_stage_window_get_pending_swaps (ClutterStageWindow *window) +void +_clutter_stage_window_schedule_update (ClutterStageWindow *window, + int sync_delay) +{ + ClutterStageWindowIface *iface; + + g_return_if_fail (CLUTTER_IS_STAGE_WINDOW (window)); + + iface = CLUTTER_STAGE_WINDOW_GET_IFACE (window); + if (iface->schedule_update == NULL) + { + g_assert (!clutter_feature_available (CLUTTER_FEATURE_SWAP_EVENTS)); + return; + } + + iface->schedule_update (window, sync_delay); +} + +gint64 +_clutter_stage_window_get_update_time (ClutterStageWindow *window) { ClutterStageWindowIface *iface; g_return_val_if_fail (CLUTTER_IS_STAGE_WINDOW (window), 0); iface = CLUTTER_STAGE_WINDOW_GET_IFACE (window); - if (iface->get_pending_swaps == NULL) + if (iface->get_update_time == NULL) { g_assert (!clutter_feature_available (CLUTTER_FEATURE_SWAP_EVENTS)); return 0; } - return iface->get_pending_swaps (window); + return iface->get_update_time (window); +} + +void +_clutter_stage_window_clear_update_time (ClutterStageWindow *window) +{ + ClutterStageWindowIface *iface; + + g_return_if_fail (CLUTTER_IS_STAGE_WINDOW (window)); + + iface = CLUTTER_STAGE_WINDOW_GET_IFACE (window); + if (iface->clear_update_time == NULL) + { + g_assert (!clutter_feature_available (CLUTTER_FEATURE_SWAP_EVENTS)); + return; + } + + iface->clear_update_time (window); } void diff --git a/clutter/clutter-stage-window.h b/clutter/clutter-stage-window.h index 041a255..27ecee0 100644 --- a/clutter/clutter-stage-window.h +++ b/clutter/clutter-stage-window.h @@ -58,7 +58,10 @@ struct _ClutterStageWindowIface void (* get_geometry) (ClutterStageWindow *stage_window, cairo_rectangle_int_t *geometry); - int (* get_pending_swaps) (ClutterStageWindow *stage_window); + void (* schedule_update) (ClutterStageWindow *stage_window, + int sync_delay); + gint64 (* get_update_time) (ClutterStageWindow *stage_window); + void (* clear_update_time) (ClutterStageWindow *stage_window); void (* add_redraw_clip) (ClutterStageWindow *stage_window, cairo_rectangle_int_t *stage_rectangle); @@ -103,7 +106,10 @@ void _clutter_stage_window_resize (ClutterStageWin gint height); void _clutter_stage_window_get_geometry (ClutterStageWindow *window, cairo_rectangle_int_t *geometry); -int _clutter_stage_window_get_pending_swaps (ClutterStageWindow *window); +void _clutter_stage_window_schedule_update (ClutterStageWindow *window, + int sync_delay); +gint64 _clutter_stage_window_get_update_time (ClutterStageWindow *window); +void _clutter_stage_window_clear_update_time (ClutterStageWindow *window); void _clutter_stage_window_add_redraw_clip (ClutterStageWindow *window, cairo_rectangle_int_t *stage_clip); diff --git a/clutter/clutter-stage.c b/clutter/clutter-stage.c index 7a82543..10ee07e 100644 --- a/clutter/clutter-stage.c +++ b/clutter/clutter-stage.c @@ -50,6 +50,7 @@ #include #define CLUTTER_DISABLE_DEPRECATION_WARNINGS +#define CLUTTER_ENABLE_EXPERIMENTAL_API #include "clutter-stage.h" #include "deprecated/clutter-stage.h" @@ -145,6 +146,8 @@ struct _ClutterStagePrivate CoglFramebuffer *active_framebuffer; + gint sync_delay; + GTimer *fps_timer; gint32 timer_n_frames; @@ -930,6 +933,7 @@ _clutter_stage_queue_event (ClutterStage *stage, { ClutterMasterClock *master_clock = _clutter_master_clock_get_default (); _clutter_master_clock_start_running (master_clock); + _clutter_stage_schedule_update (stage); } /* if needed, update the state of the input device of the event. @@ -1250,7 +1254,11 @@ clutter_stage_real_queue_relayout (ClutterActor *self) ClutterStagePrivate *priv = stage->priv; ClutterActorClass *parent_class; - priv->relayout_pending = TRUE; + if (!priv->relayout_pending) + { + _clutter_stage_schedule_update (stage); + priv->relayout_pending = TRUE; + } /* chain up */ parent_class = CLUTTER_ACTOR_CLASS (clutter_stage_parent_class); @@ -2247,6 +2255,7 @@ clutter_stage_init (ClutterStage *self) priv->use_fog = FALSE; priv->throttle_motion_events = TRUE; priv->min_size_changed = FALSE; + priv->sync_delay = -1; /* XXX - we need to keep the invariant that calling * clutter_set_motion_event_enabled() before the stage creation @@ -3558,6 +3567,10 @@ clutter_stage_ensure_redraw (ClutterStage *stage) g_return_if_fail (CLUTTER_IS_STAGE (stage)); priv = stage->priv; + + if (!priv->relayout_pending && !priv->redraw_pending) + _clutter_stage_schedule_update (stage); + priv->relayout_pending = TRUE; priv->redraw_pending = TRUE; @@ -3825,9 +3838,25 @@ clutter_stage_get_minimum_size (ClutterStage *stage, *height_p = (guint) height; } -/* Returns the number of swap buffers pending completion for the stage */ -int -_clutter_stage_get_pending_swaps (ClutterStage *stage) +void +_clutter_stage_schedule_update (ClutterStage *stage) +{ + ClutterStageWindow *stage_window; + + if (CLUTTER_ACTOR_IN_DESTRUCTION (stage)) + return; + + stage_window = _clutter_stage_get_window (stage); + if (stage_window == NULL) + return; + + return _clutter_stage_window_schedule_update (stage_window, + stage->priv->sync_delay); +} + +/* Returns the earliest time the stage is ready to update */ +gint64 +_clutter_stage_get_update_time (ClutterStage *stage) { ClutterStageWindow *stage_window; @@ -3838,7 +3867,17 @@ _clutter_stage_get_pending_swaps (ClutterStage *stage) if (stage_window == NULL) return 0; - return _clutter_stage_window_get_pending_swaps (stage_window); + return _clutter_stage_window_get_update_time (stage_window); +} + +void +_clutter_stage_clear_update_time (ClutterStage *stage) +{ + ClutterStageWindow *stage_window; + + stage_window = _clutter_stage_get_window (stage); + if (stage_window) + _clutter_stage_window_clear_update_time (stage_window); } /** @@ -3972,6 +4011,7 @@ _clutter_stage_queue_actor_redraw (ClutterStage *stage, CLUTTER_NOTE (PAINT, "First redraw request"); + _clutter_stage_schedule_update (stage); priv->redraw_pending = TRUE; master_clock = _clutter_master_clock_get_default (); @@ -4461,3 +4501,51 @@ _clutter_stage_update_state (ClutterStage *stage, return TRUE; } + +/** + * clutter_stage_set_sync_delay: + * @stage: a #ClutterStage + * @sync_delay: number of milliseconds after frame presentation to wait + * before painting the next frame. If less than zero, redraw is throttled + * to the refresh rate but not synchronized to it. + * + * This function enables an alternate behavior where Clutter draws at + * a fixed point in time after the frame presentation time (also known + * as the VBlank time). This is most useful when the application + * wants to show incoming data with predictable latency. (The primary + * example of this would be a window system compositor.) By synchronizing + * to provide new data before Clutter redraws, an external source of + * updates (in the compositor, an application) can get a reliable latency. + * + * The appropriate value of @sync_delay depends on the complexity of + * drawing the stage's scene graph - in general a value of between 0 + * and 8 ms (up to one-half of a typical 60hz frame rate) is appropriate. + * using a larger value will reduce latency but risks skipping a frame if + * drawing the stage takes too long. + */ +void +clutter_stage_set_sync_delay (ClutterStage *stage, + gint sync_delay) +{ + g_return_if_fail (CLUTTER_IS_STAGE (stage)); + + stage->priv->sync_delay = sync_delay; +} + +/** + * clutter_stage_skip_sync_delay: + * @stage: a #ClutterStage + * + * Causes the next frame for the stage to be drawn as quickly as + * possible, ignoring any delay that clutter_stage_set_sync_delay() + * would normally cause. + */ +void +clutter_stage_skip_sync_delay (ClutterStage *stage) +{ + ClutterStageWindow *stage_window; + + stage_window = _clutter_stage_get_window (stage); + if (stage_window) + _clutter_stage_window_schedule_update (stage_window, -1); +} diff --git a/clutter/clutter-stage.h b/clutter/clutter-stage.h index e3c1d7e..db3dfb1 100644 --- a/clutter/clutter-stage.h +++ b/clutter/clutter-stage.h @@ -202,6 +202,12 @@ void clutter_stage_ensure_current (ClutterStage void clutter_stage_ensure_viewport (ClutterStage *stage); void clutter_stage_ensure_redraw (ClutterStage *stage); +#ifdef CLUTTER_ENABLE_EXPERIMENTAL_API +void clutter_stage_set_sync_delay (ClutterStage *stage, + gint sync_delay); +void clutter_stage_skip_sync_delay (ClutterStage *stage); +#endif + G_END_DECLS #endif /* __CLUTTER_STAGE_H__ */ diff --git a/clutter/cogl/clutter-stage-cogl.c b/clutter/cogl/clutter-stage-cogl.c index 68b98b1..b8f091f 100644 --- a/clutter/cogl/clutter-stage-cogl.c +++ b/clutter/cogl/clutter-stage-cogl.c @@ -145,12 +145,82 @@ clutter_stage_cogl_realize (ClutterStageWindow *stage_window) return TRUE; } -static int -clutter_stage_cogl_get_pending_swaps (ClutterStageWindow *stage_window) +static void +clutter_stage_cogl_schedule_update (ClutterStageWindow *stage_window, + gint sync_delay) +{ + ClutterStageCogl *stage_cogl = CLUTTER_STAGE_COGL (stage_window); + int64_t frame_counter, frame_history_start, i; + int64_t presentation_time = 0; + int64_t refresh_interval; + int64_t now; + + if (stage_cogl->update_time != -1) + return; + + now = g_get_monotonic_time (); + + if (sync_delay < 0) + { + stage_cogl->update_time = now; + return; + } + + frame_counter = cogl_onscreen_get_frame_counter (stage_cogl->onscreen); + frame_history_start = cogl_onscreen_get_frame_history_start (stage_cogl->onscreen); + + for (i = frame_counter; i >= frame_history_start; i--) + { + CoglFrameTimings *timings; + + timings = cogl_onscreen_get_frame_timings (stage_cogl->onscreen, i); + if (timings) + { + presentation_time = cogl_frame_timings_get_presentation_time (timings); + refresh_interval = cogl_frame_timings_get_refresh_interval (timings); + } + + if (presentation_time != 0) + break; + } + + /* We only extrapolate presentation times for 150ms - this is somewhat + * arbitrary. The reasons it might not be accurate for larger times are + * that the refresh interval might be wrong or the vertical refresh + * might be downclocked if nothing is going on onscreen. + */ + if (presentation_time == 0 || presentation_time < now - 150000) + { + stage_cogl->update_time = now; + return; + } + + if (refresh_interval == 0) + refresh_interval = 16667; /* 1/60th second */ + + stage_cogl->update_time = presentation_time + 1000 * sync_delay; + + while (stage_cogl->update_time < now) + stage_cogl->update_time += refresh_interval; +} + +static gint64 +clutter_stage_cogl_get_update_time (ClutterStageWindow *stage_window) +{ + ClutterStageCogl *stage_cogl = CLUTTER_STAGE_COGL (stage_window); + + if (stage_cogl->pending_swaps) + return -1; /* in the future, indefinite */ + + return stage_cogl->update_time; +} + +static void +clutter_stage_cogl_clear_update_time (ClutterStageWindow *stage_window) { ClutterStageCogl *stage_cogl = CLUTTER_STAGE_COGL (stage_window); - return stage_cogl->pending_swaps; + stage_cogl->update_time = -1; } static ClutterActor * @@ -523,7 +593,9 @@ clutter_stage_window_iface_init (ClutterStageWindowIface *iface) iface->resize = clutter_stage_cogl_resize; iface->show = clutter_stage_cogl_show; iface->hide = clutter_stage_cogl_hide; - iface->get_pending_swaps = clutter_stage_cogl_get_pending_swaps; + iface->schedule_update = clutter_stage_cogl_schedule_update; + iface->get_update_time = clutter_stage_cogl_get_update_time; + iface->clear_update_time = clutter_stage_cogl_clear_update_time; iface->add_redraw_clip = clutter_stage_cogl_add_redraw_clip; iface->has_redraw_clips = clutter_stage_cogl_has_redraw_clips; iface->ignoring_redraw_clips = clutter_stage_cogl_ignoring_redraw_clips; @@ -570,4 +642,5 @@ _clutter_stage_cogl_class_init (ClutterStageCoglClass *klass) static void _clutter_stage_cogl_init (ClutterStageCogl *stage) { + stage->update_time = -1; } diff --git a/clutter/cogl/clutter-stage-cogl.h b/clutter/cogl/clutter-stage-cogl.h index e140824..7fc171b 100644 --- a/clutter/cogl/clutter-stage-cogl.h +++ b/clutter/cogl/clutter-stage-cogl.h @@ -35,6 +35,7 @@ struct _ClutterStageCogl CoglOnscreen *onscreen; + gint64 update_time; gint pending_swaps; unsigned int swap_callback_id; -- 1.7.12.1 From otaylor@redhat.com Tue Nov 27 15:54:08 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id A3BBE751B36 for ; Tue, 27 Nov 2012 15:54:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.27 X-Spam-Level: X-Spam-Status: No, score=-7.27 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.368, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoscCo-NvCuh for ; Tue, 27 Nov 2012 15:53:42 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by menubar.gnome.org (Postfix) with ESMTP id 6A52A751B04 for ; Tue, 27 Nov 2012 15:53:42 +0000 (UTC) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARFre5C024957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 10:53:40 -0500 Received: from lagrange.redhat.com (ovpn-113-141.phx2.redhat.com [10.3.113.141]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARFrZXE013478; Tue, 27 Nov 2012 10:53:40 -0500 From: otaylor@redhat.com To: clutter-list@gnome.org Subject: [PATCH 2/2] Call cogl_onscreen_begin_frame() Date: Tue, 27 Nov 2012 10:53:31 -0500 Message-Id: <1354031611-30960-3-git-send-email-otaylor@redhat.com> In-Reply-To: <1354031611-30960-1-git-send-email-otaylor@redhat.com> References: <1354031611-30960-1-git-send-email-otaylor@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: "Owen W. Taylor" X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:54:08 -0000 From: "Owen W. Taylor" cogl_onscreen_begin_frame() will be called implicitly called by Cogl if it isn't called before we swap to end the frame, but to get proper frame boundaries we should call it at the beginning of the frame and pass in the frame time. --- clutter/clutter-master-clock.c | 12 ++++++++++++ clutter/clutter-stage-private.h | 2 ++ clutter/clutter-stage-window.c | 13 +++++++++++++ clutter/clutter-stage-window.h | 4 ++++ clutter/clutter-stage.c | 11 +++++++++++ clutter/cogl/clutter-stage-cogl.c | 11 +++++++++++ 6 files changed, 53 insertions(+) diff --git a/clutter/clutter-master-clock.c b/clutter/clutter-master-clock.c index acd5dc8..a2f6f52 100644 --- a/clutter/clutter-master-clock.c +++ b/clutter/clutter-master-clock.c @@ -345,6 +345,16 @@ master_clock_next_frame_delay (ClutterMasterClock *master_clock) } static void +master_clock_begin_frame (ClutterMasterClock *master_clock, + GSList *stages) +{ + GSList *l; + + for (l = stages; l != NULL; l = l->next) + _clutter_stage_begin_frame (l->data, master_clock->cur_tick); +} + +static void master_clock_process_events (ClutterMasterClock *master_clock, GSList *stages) { @@ -573,6 +583,8 @@ clutter_clock_dispatch (GSource *source, master_clock->idle = FALSE; + master_clock_begin_frame (master_clock, stages); + /* Each frame is split into three separate phases: */ /* 1. process all the events; each stage goes through its events queue diff --git a/clutter/clutter-stage-private.h b/clutter/clutter-stage-private.h index 9ccba3f..4e01c19 100644 --- a/clutter/clutter-stage-private.h +++ b/clutter/clutter-stage-private.h @@ -69,6 +69,8 @@ void _clutter_stage_update_input_devices (ClutterStage *stage); void _clutter_stage_schedule_update (ClutterStage *stage); gint64 _clutter_stage_get_update_time (ClutterStage *stage); void _clutter_stage_clear_update_time (ClutterStage *stage); +void _clutter_stage_begin_frame (ClutterStage *stage, + gint64 frame_time); gboolean _clutter_stage_has_full_redraw_queued (ClutterStage *stage); ClutterActor *_clutter_stage_do_pick (ClutterStage *stage, diff --git a/clutter/clutter-stage-window.c b/clutter/clutter-stage-window.c index ffa30a1..b1cc397 100644 --- a/clutter/clutter-stage-window.c +++ b/clutter/clutter-stage-window.c @@ -175,6 +175,19 @@ _clutter_stage_window_clear_update_time (ClutterStageWindow *window) } void +_clutter_stage_window_begin_frame (ClutterStageWindow *window, + gint64 frame_time) +{ + ClutterStageWindowIface *iface; + + g_return_if_fail (CLUTTER_IS_STAGE_WINDOW (window)); + + iface = CLUTTER_STAGE_WINDOW_GET_IFACE (window); + if (iface->begin_frame != NULL) + iface->begin_frame (window, frame_time); +} + +void _clutter_stage_window_add_redraw_clip (ClutterStageWindow *window, cairo_rectangle_int_t *stage_clip) { diff --git a/clutter/clutter-stage-window.h b/clutter/clutter-stage-window.h index 27ecee0..dde77b0 100644 --- a/clutter/clutter-stage-window.h +++ b/clutter/clutter-stage-window.h @@ -62,6 +62,8 @@ struct _ClutterStageWindowIface int sync_delay); gint64 (* get_update_time) (ClutterStageWindow *stage_window); void (* clear_update_time) (ClutterStageWindow *stage_window); + void (* begin_frame) (ClutterStageWindow *stage_window, + gint64 frame_time); void (* add_redraw_clip) (ClutterStageWindow *stage_window, cairo_rectangle_int_t *stage_rectangle); @@ -110,6 +112,8 @@ void _clutter_stage_window_schedule_update (ClutterStageWin int sync_delay); gint64 _clutter_stage_window_get_update_time (ClutterStageWindow *window); void _clutter_stage_window_clear_update_time (ClutterStageWindow *window); +void _clutter_stage_window_begin_frame (ClutterStageWindow *window, + gint64 frame_time); void _clutter_stage_window_add_redraw_clip (ClutterStageWindow *window, cairo_rectangle_int_t *stage_clip); diff --git a/clutter/clutter-stage.c b/clutter/clutter-stage.c index 10ee07e..7a83f8c 100644 --- a/clutter/clutter-stage.c +++ b/clutter/clutter-stage.c @@ -3880,6 +3880,17 @@ _clutter_stage_clear_update_time (ClutterStage *stage) _clutter_stage_window_clear_update_time (stage_window); } +void +_clutter_stage_begin_frame (ClutterStage *stage, + gint64 frame_time) +{ + ClutterStageWindow *stage_window; + + stage_window = _clutter_stage_get_window (stage); + if (stage_window) + _clutter_stage_window_begin_frame (stage_window, frame_time); +} + /** * clutter_stage_set_no_clear_hint: * @stage: a #ClutterStage diff --git a/clutter/cogl/clutter-stage-cogl.c b/clutter/cogl/clutter-stage-cogl.c index b8f091f..14a4ced 100644 --- a/clutter/cogl/clutter-stage-cogl.c +++ b/clutter/cogl/clutter-stage-cogl.c @@ -223,6 +223,16 @@ clutter_stage_cogl_clear_update_time (ClutterStageWindow *stage_window) stage_cogl->update_time = -1; } +static void +clutter_stage_cogl_begin_frame (ClutterStageWindow *stage_window, + gint64 frame_time) +{ + ClutterStageCogl *stage_cogl = CLUTTER_STAGE_COGL (stage_window); + + if (stage_cogl->onscreen != NULL) + cogl_onscreen_begin_frame (stage_cogl->onscreen, frame_time); +} + static ClutterActor * clutter_stage_cogl_get_wrapper (ClutterStageWindow *stage_window) { @@ -596,6 +606,7 @@ clutter_stage_window_iface_init (ClutterStageWindowIface *iface) iface->schedule_update = clutter_stage_cogl_schedule_update; iface->get_update_time = clutter_stage_cogl_get_update_time; iface->clear_update_time = clutter_stage_cogl_clear_update_time; + iface->begin_frame = clutter_stage_cogl_begin_frame; iface->add_redraw_clip = clutter_stage_cogl_add_redraw_clip; iface->has_redraw_clips = clutter_stage_cogl_has_redraw_clips; iface->ignoring_redraw_clips = clutter_stage_cogl_ignoring_redraw_clips; -- 1.7.12.1 From robert.bragg@gmail.com Wed Nov 28 14:40:21 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6BB24751CAF for ; Wed, 28 Nov 2012 14:40:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vcr6p3Bqytw for ; Wed, 28 Nov 2012 14:40:02 +0000 (UTC) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by menubar.gnome.org (Postfix) with ESMTP id 17965751CB0 for ; Wed, 28 Nov 2012 14:40:01 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id dt10so4861661wgb.27 for ; Wed, 28 Nov 2012 06:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JcND8fgjSz0R+2bG8L0DCAjxosg5o1wzfgGpEk4+qa4=; b=yHzMCfj0kLQqWTNisqv8RQzFIrutRdvg7/HH61CjH2hWywr69WCzZmnkWHnzZttegR 05BsK6OCK7Nl8E0s22bSOy9kluaJ3RIf2pDKhjYSHChUHLgCuHPgkm/fxSsShUSSxFvo 9hoAfB66MsxWjGIgFqMUhv60DlMLTY6eovr1sxTutILJj+UIsVanuzVdYIZeTsDHMr8k qKEgxt42FH/yuuv618bWekdkdj4HJLpPJTT2g9gsnsON8+E0fwwEjlUH6xHthxHe9tWY bRvXKZVZ6UK2IKNMCO0C8gcl7+kg3bDvpNf+873algwAwMVXDl2iEMHafvaUgWsCU0ij LxMQ== MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr29739574wib.20.1354113599762; Wed, 28 Nov 2012 06:39:59 -0800 (PST) Sender: robert.bragg@gmail.com Received: by 10.216.255.131 with HTTP; Wed, 28 Nov 2012 06:39:59 -0800 (PST) In-Reply-To: <1354029539-29902-1-git-send-email-otaylor@redhat.com> References: <1354029539-29902-1-git-send-email-otaylor@redhat.com> Date: Wed, 28 Nov 2012 14:39:59 +0000 X-Google-Sender-Auth: yXNtjNC6SG9Q9hUCUg-Pt2F7mF0 Message-ID: Subject: Re: Cogl patches supporting frame timing From: Robert Bragg To: Owen Taylor Content-Type: multipart/alternative; boundary=f46d043c807019702504cf8f24b7 Cc: clutter-list@gnome.org X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 14:40:21 -0000 --f46d043c807019702504cf8f24b7 Content-Type: text/plain; charset=UTF-8 Thanks for the patches! I took a quick look at them last night they look good though I can see a few things we should talk about. I was thinking - if you don't mind - I'd quite like to move the review for these to the cogl mailinglist[1]. There's a slim chance that some people follow the cogl list but not the clutter list and later if someone wants to unravel the history of this api it might make sense if they can just search for cogl archives. kind regards, - Robert [1] http://lists.freedesktop.org/mailman/listinfo/cogl On Tue, Nov 27, 2012 at 3:18 PM, wrote: > This is a patch set for Cogl that adds support for reporting frame timing > information back as necessary to get precise information about when frames > were > scanned out to the display device. > > What I've done with it so far is used this in the Mutter compositor > to pass that information on to the application running and then used > that in GTK+ for frame timing. With this approach, I can get > audio/video synchronization in a test application to stably lock at > a known millisecond rather than having an unknown latency somewhere > in the 0-35 ms range. > > (This is in the wip/frame-synchronization branch of Cogl - there are > corresponding wip/frame-synchronization branches of Clutter (small), > Mutter, and GTK+) > > It's also useful to have information about what the refresh rate is of the > display, so I've added a framework for CoglOutput to handle information > about the properties of one display device. CoglOutput isn't fully hooked > up yet - right now I'm just using it in the GLX winsys and not exposing > it to applications. > > Other things that aren't completely finished here are: > > - I haven't really looked at other winsys - with some backends it may > simply > not be possible to get some or all of the information, and what I've > done here is that any timing value can have a value of '0' as a flag > to indicate that it isn't supplied. > > - I haven't tried to make Cogl a *consumer* of frame timing information > from a X window system compositor - the same sort of work I've done > for GTK+ should apply to the Cogl stack as well and may require a bit > of adjustment when the timing information isn't coming directly > from GL but instead from the compositor. > > _______________________________________________ > clutter-list mailing list > clutter-list@gnome.org > https://mail.gnome.org/mailman/listinfo/clutter-list > --f46d043c807019702504cf8f24b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the patches!

I took a quick look at them last= night they look good though I can see a few things we should talk about. I= was thinking - if you don't mind - I'd quite like to move the revi= ew for these to the cogl mailinglist[1]. There's a slim chance that som= e people follow the cogl list but not the clutter list and later if someone= wants to unravel the history of this api it might make sense if they can j= ust search for cogl archives.

kind regards,
- Robert

[1]=C2=A0= http://lists.freedesktop.org/mailman/listinfo/cogl

=


On Tue, Nov 27, 2012 at 3:18 PM, <ota= ylor@redhat.com> wrote:
This is a patch set for Cogl that adds support for reporting frame timing information back as necessary to get precise information about when frames = were
scanned out to the display device.

What I've done with it so far is used this in the Mutter compositor
to pass that information on to the application running and then used
that in GTK+ for frame timing. With this approach, I can get
audio/video synchronization in a test application to stably lock at
a known millisecond rather than having an unknown latency somewhere
in the 0-35 ms range.

(This is in the wip/frame-synchronization branch of Cogl - there are
corresponding wip/frame-synchronization branches of Clutter (small),
Mutter, and GTK+)

It's also useful to have information about what the refresh rate is of = the
display, so I've added a framework for CoglOutput to handle information=
about the properties of one display device. CoglOutput isn't fully hook= ed
up yet - right now I'm just using it in the GLX winsys and not exposing=
it to applications.

Other things that aren't completely finished here are:

=C2=A0- I haven't really looked at other winsys - with some backends it= may simply
=C2=A0 =C2=A0not be possible to get some or all of the information, and wha= t I've
=C2=A0 =C2=A0done here is that any timing value can have a value of '0&= #39; as a flag
=C2=A0 =C2=A0to indicate that it isn't supplied.

=C2=A0- I haven't tried to make Cogl a *consumer* of frame timing infor= mation
=C2=A0 =C2=A0from a X window system compositor - the same sort of work I= 9;ve done
=C2=A0 =C2=A0for GTK+ should apply to the Cogl stack as well and may requir= e a bit
=C2=A0 =C2=A0of adjustment when the timing information isn't coming dir= ectly
=C2=A0 =C2=A0from GL but instead from the compositor.

_______________________________________________
clutter-list mailing list
clutter-list@gnome.org
https://mail.gnome.org/mailman/listinfo/clutter-list

--f46d043c807019702504cf8f24b7-- From otaylor@redhat.com Wed Nov 28 16:49:56 2012 Return-Path: X-Original-To: clutter-list@gnome.org Delivered-To: clutter-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7591A751D53 for ; Wed, 28 Nov 2012 16:49:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.271 X-Spam-Level: X-Spam-Status: No, score=-7.271 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.369, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgQtGm+B0RV2 for ; Wed, 28 Nov 2012 16:49:37 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by menubar.gnome.org (Postfix) with ESMTP id DFD44751CE3 for ; Wed, 28 Nov 2012 16:49:37 +0000 (UTC) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qASGnZoh025001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Nov 2012 11:49:36 -0500 Received: from [10.3.113.126] (ovpn-113-126.phx2.redhat.com [10.3.113.126]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qASGnYb5001749; Wed, 28 Nov 2012 11:49:35 -0500 Message-ID: <1354121374.8093.1.camel@lagrange> Subject: Re: Cogl patches supporting frame timing From: Owen Taylor To: Robert Bragg Date: Wed, 28 Nov 2012 11:49:34 -0500 In-Reply-To: References: <1354029539-29902-1-git-send-email-otaylor@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: clutter-list@gnome.org X-BeenThere: clutter-list@gnome.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Development of \(and with\) the Clutter toolkit" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 16:49:56 -0000 On Wed, 2012-11-28 at 14:39 +0000, Robert Bragg wrote: > Thanks for the patches! > > > I took a quick look at them last night they look good though I can see > a few things we should talk about. I was thinking - if you don't mind > - I'd quite like to move the review for these to the cogl > mailinglist[1]. There's a slim chance that some people follow the cogl > list but not the clutter list and later if someone wants to unravel > the history of this api it might make sense if they can just search > for cogl archives. Sure - I checked mail.gnome.org in the offhand chance that there might be a Cogl mailing list that I didn't know about, but didn't think to look on lists.freedesktop.org. I've resent the Cogl patches there. - Owen