Re: Gtk+ win32 fixes, please test

[Alexander Larsson]

On Thu, 2011-10-20 at 01:49 +0200, Dieter Verfaillie wrote:
> On Wed, 19 Oct 2011 22:53:49 +0200, Alexander Larsson wrote:
> > I just pushed a bunch of changes to how grabs and crossing events
> > work in the win32 backend to the gtk-2-24-win32 branch, and I want to
> > fix any other leftover bugs from the client side windows conversion.
> 
>  From my first tests (on Windows XP), this looks good. Even better, it's
> amazing to see some long standing bugs finally squashed. Thank you!

I've not really used Gtk+ on windows for real, so I was mainly working
from first principles in the code fixing stuff that was obviously wrong.
Do you know of any other outstanding win32 bugs that I can look at?


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+ win32 fixes, please test

[Andy Spencer]

On 2011-10-20 09:39, Alexander Larsson wrote:
> I've not really used Gtk+ on windows for real, so I was mainly working
> from first principles in the code fixing stuff that was obviously
> wrong.  Do you know of any other outstanding win32 bugs that I can
> look at?

Thanks for your work!

In my (very) brief testing, I did not notice any regressions since 2.22.
I've had a couple long standing issues with GTK+ on windows though. I'm
not sure if they're in scope for you, but here they are..

First off, when using the MS-Windows theme, some widgets don't render
correctly and show up as black boxes. For example, notebooks with tab
position set to GTK_POS_LEFT don't render.

   http://andy753421.ath.cx/linked/aweather-gtk-2.24-test.png

Second, the GtkGLExt plugin has been broken since 2.18 I believe, the
OpenGL area doesn't get set correctly because the widget you set it on
doesn't have a native window (if I remember correctly). I've since given
up on GtkGLExt and wrote my own x11 and win32 OpenGL interfaces, so I'm
not sure if it's still an issue or not.


pgpQ8blyAfu1A.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+ win32 fixes, please test

[Alexander Larsson]

On Thu, 2011-10-20 at 08:37 +, Andy Spencer wrote:
> First off, when using the MS-Windows theme, some widgets don't render
> correctly and show up as black boxes. For example, notebooks with tab
> position set to GTK_POS_LEFT don't render.

This is possibly something else, but i'll have a look.

> Second, the GtkGLExt plugin has been broken since 2.18 I believe, the
> OpenGL area doesn't get set correctly because the widget you set it on
> doesn't have a native window (if I remember correctly). I've since given
> up on GtkGLExt and wrote my own x11 and win32 OpenGL interfaces, so I'm
> not sure if it's still an issue or not.

Peter Clifton did some work on this, and with this commit:
http://git.gnome.org/browse/gtk
+/commit/?h=gtk-2-24&id=fd01442c7e95a490607482a91987a3b72608a372

I believe GtkGLExt should nominally work (as in there might be minor
issues with it but it shouldn't be completely broken).

Please test it if you can.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+ win32 fixes, please test

[Dieter Verfaillie]

On Thu, 20 Oct 2011 08:37:35 +, Andy Spencer wrote:

First off, when using the MS-Windows theme, some widgets don't render
correctly and show up as black boxes. For example, notebooks with tab
position set to GTK_POS_LEFT don't render.

   http://andy753421.ath.cx/linked/aweather-gtk-2.24-test.png


To clarify: this happens with the "Windows Classic" theme which doesn't
use uxtheme.dll for rendering.

I'm hunting this one down as we speak, together with
https://bugzilla.gnome.org/show_bug.cgi?id=650300 and
https://bugzilla.gnome.org/show_bug.cgi?id=552681

mvg,
Dieter

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+ win32 fixes, please test

[Dieter Verfaillie]

On Thu, 20 Oct 2011 09:39:44 +0200, Alexander Larsson wrote:
I've not really used Gtk+ on windows for real, so I was mainly 
working
from first principles in the code fixing stuff that was obviously 
wrong.

Do you know of any other outstanding win32 bugs that I can look at?


It would be nice if you could take a look at this:
https://bugzilla.gnome.org/show_bug.cgi?id=552041
Have had this patch applied on 2.20, 2.22, 2.24 and now master
and have not yet encountered any problems with it. It sure wouldn't
hurt having another set of brains thinking this over though.
Also, this could eventually help with fixing
https://bugzilla.gnome.org/show_bug.cgi?id=137968

Just so you're aware, I've been working on notebook themeing:
- https://bugzilla.gnome.org/show_bug.cgi?id=650300
- https://bugzilla.gnome.org/show_bug.cgi?id=552681
and GTK_POS_LEFT and GTK_POS_RIGHT tabs being rendered as a black
rectangle when using the classic theme instead of uxtheme.
These should be finished relatively soon I hope.

Stuff I have yet to properly look into but would be nice to have fixed:
- https://bugzilla.gnome.org/show_bug.cgi?id=643138
- https://bugzilla.gnome.org/show_bug.cgi?id=644286

mvg,
Dieter

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Severe treeview performance regression (Gtk2 -> gtk3)

[Clemens Eisserer]

Hi,

Fedora16 comes with a gtk3 port of Audacious.
After updating I immediatly noticed how slow the playlist scrolls (a
quite ordinary TreeView with a few hundred lines),
when scrolling using the scrollwheel GTK3 barely keeps up, which
usually results in "afterscrolling" - on a Core2Duo with 2ghz / 4MB
cache.
GTK2's TreeView was not fast either (compared to e.g. Java's JTable),
but it didn't feel disturbing.

I hacked together a simple sample application which compiles under
gtk2 as well as gtk3: http://93.83.133.214/gtklist.c
Just maximize it (preferable on a large screen) and scroll with your
wheel - the gtk3 version should feel a lot slower.

Would be great if somebody could have a look at this regression.
I didn't file a bug-report, because usually bugzilla reports fade away
into legacy unnoticed.

Thank you in advance, Clemens
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Severe treeview performance regression (Gtk2 -> gtk3)

[Petr Tomasek]

On Thu, Oct 20, 2011 at 12:03:17PM +0200, Clemens Eisserer wrote:
> Hi,
> 
> Fedora16 comes with a gtk3 port of Audacious.
> After updating I immediatly noticed how slow the playlist scrolls (a
> quite ordinary TreeView with a few hundred lines),
> when scrolling using the scrollwheel GTK3 barely keeps up, which
> usually results in "afterscrolling" - on a Core2Duo with 2ghz / 4MB
> cache.
> GTK2's TreeView was not fast either (compared to e.g. Java's JTable),
> but it didn't feel disturbing.
> 
> I hacked together a simple sample application which compiles under
> gtk2 as well as gtk3: http://93.83.133.214/gtklist.c
> Just maximize it (preferable on a large screen) and scroll with your
> wheel - the gtk3 version should feel a lot slower.
> 
> Would be great if somebody could have a look at this regression.
> I didn't file a bug-report, because usually bugzilla reports fade away
> into legacy unnoticed.
> 
> Thank you in advance, Clemens

Hi,

I'm using gtk2 (2.22) and had (my own) small program which when I changed
2.20 -> 2.22 became teribly slow. It uses GtkTreeView. The workaround was
to switch off the sorting of the TreeView while adding a large number of
items and set it when the list is filled. Then, the TreeView became
very quick.

Maybe this is connected also to the gtk3 problem? (Anyway, it is a bug... :-( )

P.T.

-- 
Petr Tomasek 
Jabber: but...@jabbim.cz


EA 355:001  DU DU DU DU
EA 355:002  TU TU TU TU
EA 355:003  NU NU NU NU NU NU NU
EA 355:004  NA NA NA NA NA



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

regarding GIO

[Daniel Hernandez Bahr]

Hello everyone!

I've been told that this might be the best way to discuss a feature
request on GIO.
The thing is the GCancellable objects provide, as I am aware of, only
the 'cancel' feature for async operations, would it be too hurtful to
implement a GControllable class providing features such as
'pause'/'resume' as well as 'cancel' and maybe some other I fail to
recall right now??
Is this provided somewhere else and I'm missing it??

Best regards,
-- 

 Sw.E. D.H. Bahr
 Nova Desktop Development Leader
  CESOL (Free/Libre Software Centre)
UCI (University of Informatics Sciences)
Havana, Cuba



Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE 
ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
http://www.antiterroristas.cu
http://justiciaparaloscinco.wordpress.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Severe treeview performance regression (Gtk2 -> gtk3)

[Kristian Rietveld]

On Oct 20, 2011, at 12:03 PM, Clemens Eisserer wrote:
> I hacked together a simple sample application which compiles under
> gtk2 as well as gtk3: http://93.83.133.214/gtklist.c
> Just maximize it (preferable on a large screen) and scroll with your
> wheel - the gtk3 version should feel a lot slower.

I have noticed that as well on GTK+ 3 a year ago or so, and I don't think this 
is specific to GtkTreeView.  Back then I got the impression that some parts of 
the drawing "synchronization" (i.e. draw the moved area and the newly exposed 
area at the same time instead of first drawing the moved area and drawing the 
newly exposed area later) did not make it into the client-side-windows code.  
However, I was told that such problem should not exist with client side windows 
(I was not convinced though).


regards,

-kris.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Severe treeview performance regression (Gtk2 -> gtk3)

[Alexander Larsson]

On Thu, 2011-10-20 at 18:15 +0200, Kristian Rietveld wrote:
> On Oct 20, 2011, at 12:03 PM, Clemens Eisserer wrote:
> > I hacked together a simple sample application which compiles under
> > gtk2 as well as gtk3: http://93.83.133.214/gtklist.c
> > Just maximize it (preferable on a large screen) and scroll with your
> > wheel - the gtk3 version should feel a lot slower.
> 
> I have noticed that as well on GTK+ 3 a year ago or so, and I don't
> think this is specific to GtkTreeView.  Back then I got the impression
> that some parts of the drawing "synchronization" (i.e. draw the moved
> area and the newly exposed area at the same time instead of first
> drawing the moved area and drawing the newly exposed area later) did
> not make it into the client-side-windows code.  However, I was told
> that such problem should not exist with client side windows (I was not
> convinced though).

The csw code takes a lot of care to try to ensure this. However, the csw
code exists on Gtk+ 2.x too, so its easy to verify by comparing Gtk3 and
a csw version of Gtk2.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Severe treeview performance regression (Gtk2 -> gtk3)

[Clemens Eisserer]

Hi,

> The csw code takes a lot of care to try to ensure this. However, the csw
> code exists on Gtk+ 2.x too, so its easy to verify by comparing Gtk3 and
> a csw version of Gtk2.

I wonder why the gtk3 version of the treeview is so much slower
Scrolling such a basic widget on todays desktop processors shouldn't
cause any troubles (I also developed a Swing JTable and a QT version,
both scroll without any problems).

Profiling with sysprof didn't reveal a single hotspot, its quite a
flat profile with many lukewarm places.
It seems, however, painting is not the problem (both cairo and X11
stuff doesn't show anywhere near top)

Would be great if someone more experienced could have a look at the demo,
probably there are some lower-level issues that cause performance
regressions elsewhere too.


Thanks, Clemens
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Severe treeview performance regression (Gtk2 -> gtk3)

[Allin Cottrell]

On Thu, 20 Oct 2011, Clemens Eisserer wrote:


The csw code takes a lot of care to try to ensure this. However, the csw
code exists on Gtk+ 2.x too, so its easy to verify by comparing Gtk3 and
a csw version of Gtk2.


I wonder why the gtk3 version of the treeview is so much slower
Scrolling such a basic widget on todays desktop processors shouldn't
cause any troubles (I also developed a Swing JTable and a QT version,
both scroll without any problems).

Profiling with sysprof didn't reveal a single hotspot, its quite a
flat profile with many lukewarm places.
It seems, however, painting is not the problem (both cairo and X11
stuff doesn't show anywhere near top)

Would be great if someone more experienced could have a look at the demo,
probably there are some lower-level issues that cause performance
regressions elsewhere too.


I compiled your gtklist.c using

(a) gtk-2.24.7 and friends (latest stable stack)
(b) gtk-3.2.1  and friends (again, all latest stable)

I can't detect any difference in the scrolling performance in 
the two cases; it seems quite acceptable in both. This is on 
Linux 3.0.7, glibc 2.14, gcc 4.6.1, Core i5 2520M 2.50GHz,

Lenovo Thinkpad with "wheel-type" scrolling via Trackpad.

Allin Cottrell

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Severe treeview performance regression (Gtk2 -> gtk3)

[Clemens Eisserer]

Hi Allin,

> (a) gtk-2.24.7 and friends (latest stable stack)
> (b) gtk-3.2.1  and friends (again, all latest stable)
>
> I can't detect any difference in the scrolling performance in the two cases;
> it seems quite acceptable in both. This is on Linux 3.0.7, glibc 2.14, gcc
> 4.6.1, Core i5 2520M 2.50GHz,
> Lenovo Thinkpad with "wheel-type" scrolling via Trackpad.

Thanks for testing :)

I am on Fedora-16 with gtk-3.2.0-1 using the gtk3's default theme I
can easily produce several seconds of "after-scrolling",
however I have a large monitor (1920x1200). gtk2 is gtk2-2.24.6 with
"Mist" theme.
Both results are not good, even with gtk2 I can't just grab the slider
and scroll without stuttering (which works with Java and QT),
however with gtk3 its a lot slower. How much is hard to quantify
without frameworks available to measure.

Your CPU is about ~50% faster than mine - probably that's just enough
to not let scroll-events queue up?

Thanks, Clemens
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Severe treeview performance regression (Gtk2 -> gtk3)

[Allin Cottrell]

On Thu, 20 Oct 2011, Clemens Eisserer wrote:


Hi Allin,


(a) gtk-2.24.7 and friends (latest stable stack)
(b) gtk-3.2.1  and friends (again, all latest stable)

I can't detect any difference in the scrolling performance in the two cases;
it seems quite acceptable in both. This is on Linux 3.0.7, glibc 2.14, gcc
4.6.1, Core i5 2520M 2.50GHz,
Lenovo Thinkpad with "wheel-type" scrolling via Trackpad.


Thanks for testing :)

I am on Fedora-16 with gtk-3.2.0-1 using the gtk3's default theme I
can easily produce several seconds of "after-scrolling",
however I have a large monitor (1920x1200). gtk2 is gtk2-2.24.6 with
"Mist" theme.
Both results are not good, even with gtk2 I can't just grab the slider
and scroll without stuttering (which works with Java and QT),
however with gtk3 its a lot slower. How much is hard to quantify
without frameworks available to measure.

Your CPU is about ~50% faster than mine - probably that's just enough
to not let scroll-events queue up?


Possibly. Since you mention themes, I should say that with 
both gtk2 and gtk3 I'm using "no theme", just the plain 
vanilla out-of-the-box gtk appearance (which looks much better 
in gtk2). I don't know how relevant this is to scrolling 
speed.


Allin___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Severe treeview performance regression (Gtk2 -> gtk3)

[Lionel Landwerlin]

GtkList isn't based on treeview AFAIK

Allin Cottrell  wrote:

>On Thu, 20 Oct 2011, Clemens Eisserer wrote:
>
>>> The csw code takes a lot of care to try to ensure this. However, the csw
>>> code exists on Gtk+ 2.x too, so its easy to verify by comparing Gtk3 and
>>> a csw version of Gtk2.
>>
>> I wonder why the gtk3 version of the treeview is so much slower
>> Scrolling such a basic widget on todays desktop processors shouldn't
>> cause any troubles (I also developed a Swing JTable and a QT version,
>> both scroll without any problems).
>>
>> Profiling with sysprof didn't reveal a single hotspot, its quite a
>> flat profile with many lukewarm places.
>> It seems, however, painting is not the problem (both cairo and X11
>> stuff doesn't show anywhere near top)
>>
>> Would be great if someone more experienced could have a look at the demo,
>> probably there are some lower-level issues that cause performance
>> regressions elsewhere too.
>
>I compiled your gtklist.c using
>
>(a) gtk-2.24.7 and friends (latest stable stack)
>(b) gtk-3.2.1  and friends (again, all latest stable)
>
>I can't detect any difference in the scrolling performance in 
>the two cases; it seems quite acceptable in both. This is on 
>Linux 3.0.7, glibc 2.14, gcc 4.6.1, Core i5 2520M 2.50GHz,
>Lenovo Thinkpad with "wheel-type" scrolling via Trackpad.
>
>Allin Cottrell
>
>___
>gtk-devel-list mailing list
>gtk-devel-list@gnome.org
>http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Severe treeview performance regression (Gtk2 -> gtk3)

[David Nečas]

On Thu, Oct 20, 2011 at 09:45:10PM +0100, Lionel Landwerlin wrote:
> GtkList isn't based on treeview AFAIK

Please look at the source code before making such remarks.

Anyway, I was about to note that I observed the Gtk+3 version to be
faster (both version from Fedora 15 packages).  But then I realized that
while Gtk+3 uses the default theme the Gtk+2 theme is Glider.  After
fixing that the subjective performance was pretty much the same.

Yeti

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

missing gdaui entrys functions in distribution

[Renato Merli]

Hi,


  I've found libgda-ui functions for specialized entrys on libgda
source code that are not in the reference.
  The author of C++ wrappers also told that they are not in the
package distribution also, but i didnt check it yet.
  Can anyone fix the configue scripts to install functions on
libgda-ui/data-entries folder ? Theres a way to use entries without
these functions, but it dont give the possibility to inherit from
specialized entrys.
  It would be nice for libgda-uimm creators if someone could also
write some references and a class diagram.
  Lets make current libgda usable with all its features.
  Thanks


-- 

Renato Merli
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: missing gdaui entrys functions in distribution

[Renato Merli]

Regarding last message... i am using 4.99 version of libgda, newer
versions dont compile and are not the ones in use by c++ layer
developers


2011/10/20 Renato Merli :
> Hi,
>
>
>  I've found libgda-ui functions for specialized entrys on libgda
> source code that are not in the reference.
>  The author of C++ wrappers also told that they are not in the
> package distribution also, but i didnt check it yet.
>  Can anyone fix the configue scripts to install functions on
> libgda-ui/data-entries folder ? Theres a way to use entries without
> these functions, but it dont give the possibility to inherit from
> specialized entrys.
>  It would be nice for libgda-uimm creators if someone could also
> write some references and a class diagram.
>  Lets make current libgda usable with all its features.
>  Thanks
>
>
> --
>
> Renato Merli
>



-- 

Renato Merli
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+ win32 fixes, please test

[Andy Spencer]

On 2011-10-20 10:47, Alexander Larsson wrote:
> I believe GtkGLExt should nominally work (as in there might be minor
> issues with it but it shouldn't be completely broken).
> 
> Please test it if you can.

It seems your latest 2.24 seems to work with GtkGLExt, sorry about the
noise.


pgp2gYMj86R8t.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+ win32 fixes, please test

[Andy Spencer]

On 2011-10-20 11:37, Dieter Verfaillie wrote:
> On Thu, 20 Oct 2011 08:37:35 +, Andy Spencer wrote:
> > First off, when using the MS-Windows theme, some widgets don't render
> > correctly and show up as black boxes. For example, notebooks with tab
> > position set to GTK_POS_LEFT don't render.
> >
> >http://andy753421.ath.cx/linked/aweather-gtk-2.24-test.png
> 
> To clarify: this happens with the "Windows Classic" theme which doesn't
> use uxtheme.dll for rendering.

I tried it with the normal Windows XP Silver theme and my program won't
run at all using the MS-Windows GTK+ theme. It segfault on startup.. The
testnotebookdnd program that comes with the new 2.24 bundle runs, so
it's possibly a problem with my application. I probably won't have a
chance to do much debugging during the next week or so though..

I did notice however, that using the MS-Windows/Silver theme causes the
testnotebookdnd program to crash when you try to drag the right-most
'beer' tab off onto the desktop.


pgpR0N75u2jgg.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list