Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-10-01 Thread Petr Tomasek 
On Wed, Sep 30, 2009 at 05:51:56PM +0100, Ross Burton wrote:
> On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote:
> > (Btw, this infrastructure is not specific to the gphoto2:// GVfs
> > backend; any GVfs backend can use it - say, a Flickr backend).
> 
> Bad example, downloading the original file (no seeking in HTTP) just to

HTTP_RANGE?


-- 
Petr Tomasek 
Jabber: but...@jabbim.cz
SIP: but...@ekiga.net
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-10-01 Thread Ross Burton 
On Thu, 2009-10-01 at 16:00 +0200, Petr Tomasek wrote:
> On Wed, Sep 30, 2009 at 05:51:56PM +0100, Ross Burton wrote:
> > On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote:
> > > (Btw, this infrastructure is not specific to the gphoto2:// GVfs
> > > backend; any GVfs backend can use it - say, a Flickr backend).
> > 
> > Bad example, downloading the original file (no seeking in HTTP) just to
> 
> HTTP_RANGE?

Thanks to latency I imagine it would actually be faster to download the
entire image than attempt to "seek" around a file over HTTP.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: filesystemmodel branch - initial testing

2009-10-01 Thread Matthias Clasen 
On Thu, Oct 1, 2009 at 1:21 AM, Xan Lopez  wrote:

> From that I take that the plan is to release this in 2.18.2? Wouldn't
> it be a much better idea to only go for it in the unstable 2.19.x
> series? At least this is not the kind of change I'd expect to receive
> in a minor incremental bugfix release of the stable series.

If the improvements are as impressive as Federico makes them sound,
then I think getting them into 2.18 (and thus out to users) would be a
nice thing, imo.

Of course, there is some risk, so we need to test and review
carefully. But Federico is doing that, and I'll look over the patch
myself, too.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: filesystemmodel branch - initial testing

2009-10-01 Thread Federico Mena Quintero 
On Thu, 2009-10-01 at 01:48 +0100, Bastien Nocera wrote:

> Not having looked at the code since the original patches, have all the
> concerns about the possible regressions and incremental changes been
> addressed?

I did a *very* careful review of the code, and it seems sane.  If you
look at the "filesystemmodel" branch, you'll see essentially these
commits:

 - one-shot rewrite of GtkFileSystemModel
 - Company's extra fixes, adapting GtkFileChooserDefault to use it
 - Cleanup of GtkFileChooserDefault to make recent/search use the model
 - Federico's nitpicks, cleanups, a few bug fixes
 - A big in-source comment explaining how the new model works

Basically, I'm happy that we have a) at least two people who know how
the model works; b) documentation on it, for posterity.  We had neither
of those with the old GtkFileSystemModel :)

I hope there will be no be regressions with the file chooser's behavior;
the code doesn't touch that.  It's all concerned with how the file list
is shown.

Of course, help with testing is much appreciated.  I'll merge master to
the filesystemmodel branch to get in the unrelated fixes in master, and
then you can test that easily.

  Federico

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

Re: filesystemmodel branch - initial testing

2009-10-01 Thread Federico Mena Quintero 
On Thu, 2009-10-01 at 11:20 -0400, Matthias Clasen wrote:

> If the improvements are as impressive as Federico makes them sound,
> then I think getting them into 2.18 (and thus out to users) would be a
> nice thing, imo.

Basically, before the filesystemmodel branch, I dreaded using the file
chooser to visit my ~ or ~/Downloads (two big dumpsters in my file
system).  Now both appear semi-instantaneously after clicking on those
folders, and they are not slowed down by loading thumbnails (something
which was a big problem for me before).

An eyeballed test in a directory of 10K empty files showed 3 seconds for
the new branch, versus 9 seconds for the old branch.

I'd love it if people could test slow networked directories.

> Of course, there is some risk, so we need to test and review
> carefully. But Federico is doing that, and I'll look over the patch
> myself, too.

Sure, thanks.  You may want to start by reading the big comment near the
beginning of gtkfilesystemmodel.c, and then by looking at the actual
code.

  Federico

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

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-10-01 Thread Mark 
On Thu, Oct 1, 2009 at 4:31 PM, Ross Burton  wrote:
> On Thu, 2009-10-01 at 16:00 +0200, Petr Tomasek wrote:
>> On Wed, Sep 30, 2009 at 05:51:56PM +0100, Ross Burton wrote:
>> > On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote:
>> > > (Btw, this infrastructure is not specific to the gphoto2:// GVfs
>> > > backend; any GVfs backend can use it - say, a Flickr backend).
>> >
>> > Bad example, downloading the original file (no seeking in HTTP) just to
>>
>> HTTP_RANGE?
>
> Thanks to latency I imagine it would actually be faster to download the
> entire image than attempt to "seek" around a file over HTTP.
>
> Ross
> --
> Ross Burton                                 mail: r...@burtonini.com
>                                          jabber: r...@burtonini.com
>                                           www: http://burtonini.com

I made a nice image of my last benchmark:
http://img36.imageshack.us/i/scalingperformance.png/

The one with just 21 seconds is where all my images are in cache.
That's also where all my cores are working at 100%
The other thread benchmark (70 seconds) vauses all cores to work at ~40%
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Are Out-of-Tree Widgets Second-Class Citizens?

2009-10-01 Thread Cody Russell 
On Mon, 2009-09-28 at 15:12 -0400, Morten Welinder wrote:
> This is a consequence of the halfway G_SEALing that was done.  Insofar
> G_SEAL
> is a good idea, it should apply to GTK+ itself, i.e., GtkLabel has no
> business
> messing with the internals of GtkWidget, although obviously it should
> have access
> to its own internals.  (Doing so would also send some of the
> conversion pain
> back to people who inflict it on others.  That might discourage the
> habit of
> breaking APIs and ABIs without good reason.) 

This is part of the plan for 3.0.  I think the original idea was that
2.18 or 2.90 would GSEAL everything, and 3.0 would actually remove those
struct members.  This obviously means that it won't have access to those
members anymore and it will have to use either the public APIs or the
members of private structs.

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