Thumbnailing service project; opinions, suggestions?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Thumbnailing service project; opinions, suggestions?

Bugzilla from markg85@gmail.com
Hi,

on school i study Computer Science. That exists of a dozen "Major"
semesters and a few "Minor" semesters. Each lasts 10 weeks and that
for 3 years.
So this project, described in depth below, will have to be done within
10 school weeks of which the first 8 are the "creation" weeks. After
that it gets rated by my teachers and i either pass or fail it.
Now on school i want to learn the following coding methods in a Minor
part. A minor is a part where i "can" compose my own semester and i
did it with the following "demands" as in methods i want to learn in
that semester:

•       Plugin architecture
•       Asynchronous
•       Multi-threaded
•       Design patterns
•       Data structures (hash, queue, stack etc...)

And the methods that will be in it but already "known" to me

•       Daemon
•       IPC (D-Bus)

Now i've read the wish on this list to make a thumbnailing service for
a generic central way to generate thumbnails.
All of the above methods can be used in a thumbnailing service. So, i
made a proposal on school to make just that, a thumbnailing service
with a plugin architecture.

Is this been done before?
-------------------------
Well, not done before but a group of people is doing it as we speak:
http://live.gnome.org/ThumbnailerSpec ... i mailed them roughly this
mail a week ago to see if we could work together on this but i sadly
had to conclude that their project is in the final stages before release
1 so there would only be documenting and bug fixing. That is also part
of my semester but not the only part. I want to learn more then just
bug hunting and documentation stuff and for that there is no room in
their project thus i ended up concluding that i can't join them for the
simple fact that my school would probably not allow that as a project.

So, in roughly 13 weeks time (3 weeks in the current semester then the
10 weeks for this project) the Gnome community will have the ability to
choose between 2 thumbnailing services. That is not a maybe but a
certainty. Why? Well, i made this proposal on school, it got approved so
now i simply have to make it in order to pass the semester.

Will i be compatible with their dbus thumbnailing spec? Perhaps..
perhaps not. I do need to design the project before i start making the
actual code (major part of the project) but i do not know if i will
stick to the dbus rules they made. I can see some problems coming there
if you have huge folders to thumbnail that flood dbus.. O well, time
tell the answer to this.

Thumbnailing service
-------------------------
The idea in short is:
The daemon holds the plugin framework and knows how to handle certain
things (to be determined) defined by class templates and interfaces.
A plugin can then for example say something like this (in readable
language instead of code):
"Hey, i'm the FFMPEG plugin and i can handle the following extensions
<<long list of extensions>>"
Plugins should be placed in a folder after which a daemon update
(through dbus?) should be executed to load and activate the plugins.

So, what you get with this is a thumbnailing service that has plugins
(the pure service only holds the plugin architecture and lists from
extensions to plugins provided by the plugins).
That also means there will be a pixbuf plugin to read the default glib
images. (more on this one later after optimizing)

Another thing which i see as needed but is not part of this school
project is making a allowed/denied list in the daemon that contains
the extensions allowed to thumbnail besides the extensions available to
make thumbnails from. The idea is that you tell the thumbnailing daemon
through dbus or by reading gconf keys which extensions are allowed
(or not allowed).

Then for the dbus part. The idea is to let a application (for example
nautilus) request the thumbnails from their full scale file paths.
then the daemon should return the new file path to the thumbnails. That
is one way but could potential be a issue with folders that contain
thousands of files.

Another way to do this is: let nautilus send the folder that needs to
be thumbnailed. then the daemon should read the folder, check if a
thumbnail already exists and make it if not. The daemon should then
(as long as it's busy) send updates (let’s say every 0.1 second) to
nautilus with the files that have been thumbnailed.

What probably might be a better idea is to let nautilus look in the
folder and see which files need to be thumbnailed instead of handling
that task to the daemon. Then nautilus can send the list of files that
need to be thumbnailed to the daemon.

Yet another possible way where i have no clue if it's possible is
making a file list hash (or map or vector or. anything) in nautilus that
contains the files that needs to be thumbnailed. Nautilus should filter
out the ones that are already thumbnailed. Then the pointer of that hash
(let’s call it a hash for now) should be send to the thumbnailing daemon
where the thumbnails are being made and returned in another hash
(also provided by nautilus). I have no idea if this is for one even
possible and if it's wise to just pointers from one app to another.
If this gets to complex for the scope of this school project then the
simple solution (aka the first method) will be used.

The intention (and requirement) is to make this daemon asynchronous so
it won't block if another application suddenly wants to request
thumbnails.

Optimizing
-------------------------
Since the project didn't seem complex enough on paper (can you believe
that!) i was forced to add one more thing. Luckily i already wanted to
do something with optimizing in Gnome/glib so i added it to the paper.

The idea with the optimizing is making the thumbnail generation as
fast as possible! If you've been reading the gtk devel list lately you
must have noticed that i already did quite a lot to make thumbnail
generation as fast as possible. The latest benchmark so far:
http://img36.imageshack.us/i/scalingperformance.png/
which shows a significant speed improvement when using threaded
thumbnailing. This mean that the intended optimizing part is already
partly done but could be improved more by using threaded thumbnailing
with gnome_thumbnail_scale_down_pixbuff in combination with
gdk_pixbuff_new_from_file_at_scale.

About the image; with the 70 seconds bar my cpu cores (4) ran at 40%
each and i had "50%" iowait in iostat. The 21 seconds is when the
images are cached then all cores ran at 100% resulting at 21 seconds.
The benchmarks are all done with the bilinear flag set where possible
for the best quality thumbnails.

When that's working in the daemon it might be possible to speed up the
rendering of the thumbnails in nautilus (the gtk part of it) by batch
rendering the available thumbnails if that's not done already. Let’s say
a nautilus redraw every 0.2 seconds till all thumbnails are visible.

There are more optimiz ways like using OpenCL or Cairo! more about them
just below.

GdkPixbuf? Cairo? OpenCL?
-------------------------
First GdkPixbuf. I have been told that the current GdkPixbuf "sucks" and
should probably be avoided when attempting to make thumbnails as fast
as possible. One of the reasons to avoid it where Cairo. If i wanted to
have hardware accelerated downscaling i first need to make a Cairo
object and from there i need to make a Xlib object. Then i can save it
with cairo but only in .png and i personally want to be able to pick
JPEG2000 and JPEG as well. Now i have been told that only the steps of
converting a GdkPixbuf to a Xlib object could take so long that there is
hardly speed to gain there. So for that i would have to avoid GdkPixbuf
and take a more direct aproach. Note that this does fall outside the
scope of this school project but it would just be nice to have.

As for OpenCl. I am havily in favor of that method but my hardware
configuration is sadly the most horrible one to choose. Intel CPU
and nvidia GPU. there are no stable releases for the GPU yet on linux
and for the CPU there isn't a driver so i have no OpenCL options.
However if this becomes possible during my project i will certainly
attempt to implement it.

Repository?
-------------------------
I would love to have a repository for this on the Gnome servers. Would
that be possible? it would be my first ever GIT repo. If this is not
going to be allowed then it's either going to be a github, gitorious or
google code repository. The code will be publicly available with the
GPL (v2 or v3) license.

Blog or Log?
-------------------------
I also would like to make daily or weekly posts of the progress. I can
do that on my own blog but would it then be allowed that my blog is
readable on planet gtk or planet gnome (or both)?

Gnome subdomain?
-------------------------
If the Repository can't be with gnome i will probably just use my site
whatever those other 3 repo providers offer. But i would like to have
a gnome sub domain for example: thumbnailing-service.gnome.org or some
other name (i still have to make up a name for this project).

Conclusion
-------------------------
As said there was the wish to make this. I made this proposal on
school and it got accepted. This means i __have__ to make it now.
That's a risk but in the worst case scenario i just gain knowledge with
the methods above. In reality i hope this to be useful and perhaps even
viable for inclusion in Gnome. It might result in a rewrite to be good
enough for gnome ^_^. My intention certainly is to make it usable in
gnome whether that is as just a app of mine or a app distributed with
every new gnome release.. the latter option would be the best one.

The approved school document
-------------------------
I sadly can't give it. It's written in dutch. If you are dutch or want
to translate it to english you can get it. It's 12 pages of which 3 are
scheduling pages which can be trashed. The text in this mail describes
it more in depth then the approved document since that needed to be
"general".

Feedback
-------------------------
I hope some people could post their opinions about this, where can
more optimizing things be done that fall in this scope, did i miss
features for the thumbnialing service? etc.. etc.. Your feedback would
be greatly appreciated.

Thanx a lot for reading this long mail,
Mark
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Rob Taylor-3
Hi Mark,

We already have a thumbnailing service that is only just now starting to
be used. A complete reimplementation of soemthing existing will not be a
very useful thing. I also suggest that 13weeks for your entire plan is
very over optimistic. I would suggest a better option would be to do a
library with optimised thumbnailing routines. This would also be very
useful for existng projects and probably result in you code being used
in a number of situations. To add complexity you could also branch out
into making thumbnail clips for videos. If you write up such a plan
completely, i think you'd find it's more than enough work for a 13 week
project.

Thanks,
Rob

Mark wrote:

> Hi,
>
> on school i study Computer Science. That exists of a dozen "Major"
> semesters and a few "Minor" semesters. Each lasts 10 weeks and that
> for 3 years.
> So this project, described in depth below, will have to be done within
> 10 school weeks of which the first 8 are the "creation" weeks. After
> that it gets rated by my teachers and i either pass or fail it.
> Now on school i want to learn the following coding methods in a Minor
> part. A minor is a part where i "can" compose my own semester and i
> did it with the following "demands" as in methods i want to learn in
> that semester:
>
> •       Plugin architecture
> •       Asynchronous
> •       Multi-threaded
> •       Design patterns
> •       Data structures (hash, queue, stack etc...)
>
> And the methods that will be in it but already "known" to me
>
> •       Daemon
> •       IPC (D-Bus)
>
> Now i've read the wish on this list to make a thumbnailing service for
> a generic central way to generate thumbnails.
> All of the above methods can be used in a thumbnailing service. So, i
> made a proposal on school to make just that, a thumbnailing service
> with a plugin architecture.
>
> Is this been done before?
> -------------------------
> Well, not done before but a group of people is doing it as we speak:
> http://live.gnome.org/ThumbnailerSpec ... i mailed them roughly this
> mail a week ago to see if we could work together on this but i sadly
> had to conclude that their project is in the final stages before release
> 1 so there would only be documenting and bug fixing. That is also part
> of my semester but not the only part. I want to learn more then just
> bug hunting and documentation stuff and for that there is no room in
> their project thus i ended up concluding that i can't join them for the
> simple fact that my school would probably not allow that as a project.
>
> So, in roughly 13 weeks time (3 weeks in the current semester then the
> 10 weeks for this project) the Gnome community will have the ability to
> choose between 2 thumbnailing services. That is not a maybe but a
> certainty. Why? Well, i made this proposal on school, it got approved so
> now i simply have to make it in order to pass the semester.
>
> Will i be compatible with their dbus thumbnailing spec? Perhaps..
> perhaps not. I do need to design the project before i start making the
> actual code (major part of the project) but i do not know if i will
> stick to the dbus rules they made. I can see some problems coming there
> if you have huge folders to thumbnail that flood dbus.. O well, time
> tell the answer to this.
>
> Thumbnailing service
> -------------------------
> The idea in short is:
> The daemon holds the plugin framework and knows how to handle certain
> things (to be determined) defined by class templates and interfaces.
> A plugin can then for example say something like this (in readable
> language instead of code):
> "Hey, i'm the FFMPEG plugin and i can handle the following extensions
> <<long list of extensions>>"
> Plugins should be placed in a folder after which a daemon update
> (through dbus?) should be executed to load and activate the plugins.
>
> So, what you get with this is a thumbnailing service that has plugins
> (the pure service only holds the plugin architecture and lists from
> extensions to plugins provided by the plugins).
> That also means there will be a pixbuf plugin to read the default glib
> images. (more on this one later after optimizing)
>
> Another thing which i see as needed but is not part of this school
> project is making a allowed/denied list in the daemon that contains
> the extensions allowed to thumbnail besides the extensions available to
> make thumbnails from. The idea is that you tell the thumbnailing daemon
> through dbus or by reading gconf keys which extensions are allowed
> (or not allowed).
>
> Then for the dbus part. The idea is to let a application (for example
> nautilus) request the thumbnails from their full scale file paths.
> then the daemon should return the new file path to the thumbnails. That
> is one way but could potential be a issue with folders that contain
> thousands of files.
>
> Another way to do this is: let nautilus send the folder that needs to
> be thumbnailed. then the daemon should read the folder, check if a
> thumbnail already exists and make it if not. The daemon should then
> (as long as it's busy) send updates (let’s say every 0.1 second) to
> nautilus with the files that have been thumbnailed.
>
> What probably might be a better idea is to let nautilus look in the
> folder and see which files need to be thumbnailed instead of handling
> that task to the daemon. Then nautilus can send the list of files that
> need to be thumbnailed to the daemon.
>
> Yet another possible way where i have no clue if it's possible is
> making a file list hash (or map or vector or. anything) in nautilus that
> contains the files that needs to be thumbnailed. Nautilus should filter
> out the ones that are already thumbnailed. Then the pointer of that hash
> (let’s call it a hash for now) should be send to the thumbnailing daemon
> where the thumbnails are being made and returned in another hash
> (also provided by nautilus). I have no idea if this is for one even
> possible and if it's wise to just pointers from one app to another.
> If this gets to complex for the scope of this school project then the
> simple solution (aka the first method) will be used.
>
> The intention (and requirement) is to make this daemon asynchronous so
> it won't block if another application suddenly wants to request
> thumbnails.
>
> Optimizing
> -------------------------
> Since the project didn't seem complex enough on paper (can you believe
> that!) i was forced to add one more thing. Luckily i already wanted to
> do something with optimizing in Gnome/glib so i added it to the paper.
>
> The idea with the optimizing is making the thumbnail generation as
> fast as possible! If you've been reading the gtk devel list lately you
> must have noticed that i already did quite a lot to make thumbnail
> generation as fast as possible. The latest benchmark so far:
> http://img36.imageshack.us/i/scalingperformance.png/
> which shows a significant speed improvement when using threaded
> thumbnailing. This mean that the intended optimizing part is already
> partly done but could be improved more by using threaded thumbnailing
> with gnome_thumbnail_scale_down_pixbuff in combination with
> gdk_pixbuff_new_from_file_at_scale.
>
> About the image; with the 70 seconds bar my cpu cores (4) ran at 40%
> each and i had "50%" iowait in iostat. The 21 seconds is when the
> images are cached then all cores ran at 100% resulting at 21 seconds.
> The benchmarks are all done with the bilinear flag set where possible
> for the best quality thumbnails.
>
> When that's working in the daemon it might be possible to speed up the
> rendering of the thumbnails in nautilus (the gtk part of it) by batch
> rendering the available thumbnails if that's not done already. Let’s say
> a nautilus redraw every 0.2 seconds till all thumbnails are visible.
>
> There are more optimiz ways like using OpenCL or Cairo! more about them
> just below.
>
> GdkPixbuf? Cairo? OpenCL?
> -------------------------
> First GdkPixbuf. I have been told that the current GdkPixbuf "sucks" and
> should probably be avoided when attempting to make thumbnails as fast
> as possible. One of the reasons to avoid it where Cairo. If i wanted to
> have hardware accelerated downscaling i first need to make a Cairo
> object and from there i need to make a Xlib object. Then i can save it
> with cairo but only in .png and i personally want to be able to pick
> JPEG2000 and JPEG as well. Now i have been told that only the steps of
> converting a GdkPixbuf to a Xlib object could take so long that there is
> hardly speed to gain there. So for that i would have to avoid GdkPixbuf
> and take a more direct aproach. Note that this does fall outside the
> scope of this school project but it would just be nice to have.
>
> As for OpenCl. I am havily in favor of that method but my hardware
> configuration is sadly the most horrible one to choose. Intel CPU
> and nvidia GPU. there are no stable releases for the GPU yet on linux
> and for the CPU there isn't a driver so i have no OpenCL options.
> However if this becomes possible during my project i will certainly
> attempt to implement it.
>
> Repository?
> -------------------------
> I would love to have a repository for this on the Gnome servers. Would
> that be possible? it would be my first ever GIT repo. If this is not
> going to be allowed then it's either going to be a github, gitorious or
> google code repository. The code will be publicly available with the
> GPL (v2 or v3) license.
>
> Blog or Log?
> -------------------------
> I also would like to make daily or weekly posts of the progress. I can
> do that on my own blog but would it then be allowed that my blog is
> readable on planet gtk or planet gnome (or both)?
>
> Gnome subdomain?
> -------------------------
> If the Repository can't be with gnome i will probably just use my site
> whatever those other 3 repo providers offer. But i would like to have
> a gnome sub domain for example: thumbnailing-service.gnome.org or some
> other name (i still have to make up a name for this project).
>
> Conclusion
> -------------------------
> As said there was the wish to make this. I made this proposal on
> school and it got accepted. This means i __have__ to make it now.
> That's a risk but in the worst case scenario i just gain knowledge with
> the methods above. In reality i hope this to be useful and perhaps even
> viable for inclusion in Gnome. It might result in a rewrite to be good
> enough for gnome ^_^. My intention certainly is to make it usable in
> gnome whether that is as just a app of mine or a app distributed with
> every new gnome release.. the latter option would be the best one.
>
> The approved school document
> -------------------------
> I sadly can't give it. It's written in dutch. If you are dutch or want
> to translate it to english you can get it. It's 12 pages of which 3 are
> scheduling pages which can be trashed. The text in this mail describes
> it more in depth then the approved document since that needed to be
> "general".
>
> Feedback
> -------------------------
> I hope some people could post their opinions about this, where can
> more optimizing things be done that fall in this scope, did i miss
> features for the thumbnialing service? etc.. etc.. Your feedback would
> be greatly appreciated.
>
> Thanx a lot for reading this long mail,
> Mark
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list


--
Rob Taylor, Codethink Ltd. - http://codethink.co.uk
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Jannis Pohlmann-3
In reply to this post by Bugzilla from markg85@gmail.com
Hey,

On Mon, 19 Oct 2009 16:32:29 +0200
Mark <[hidden email]> wrote:

> Is this been done before?
> -------------------------
> Well, not done before but a group of people is doing it as we speak:
> http://live.gnome.org/ThumbnailerSpec ... i mailed them roughly this
> mail a week ago to see if we could work together on this but i sadly
> had to conclude that their project is in the final stages before
> release 1

Let me just add that http://live.gnome.org/ThumbnailerSpec has received
a hell lot of love recently. In its current state, the spec defines
versioned D-Bus interfaces and methods for:

  - requesting thumbnails asynchronously
  - requesting a list of supported URI scheme / MIME type pairs
  - requesting a list of supported schedulers
  - updating the thumbnail cache (e.g. as defined by the thumbnail
    managing standard) when files are deleted/moved/renamed
  - implementing specialized (custom or proprietary) thumbnailer
    services
  - registering specialized thumbnailer services at runtime

Specialized thumbnailer services can also be installed permanently by
installing a .desktop file into the system.

An earlier version of the spec was implemented by Philip (called
hildon-thumbnail). Earlier this year, I started a new implementation
called Tumbler. It can be found on

  http://git.xfce.org/apps/tumbler/

and is currently being prepared for inclusion in Xfce as well as Maemo
(http://maemo.gitorious.org/maemo-af/tumbler, replacing
hildon-thumbnail). Tumbler aims to be a complete implementation of the
spec. In addition to everything defined in the spec it also provides a
plugin API for thumbnailer and cache plugins (it currently ships a
GdkPixbuf and a FreeType font thumbnailer plugin as well as a cache
implementation for the thumbnail managing standard). This helps
reducing D-Bus traffic because on the desktop with applications like
file managers using it, it is kinda important not to have more than a
few services running for thumbnailing different file types.
At the moment, there are two different schedulers (for foreground and
background requests). The whole thing could probably use a little more
optimizing but it's in a pretty good shape already.

Thunar and Maemo are two very different usage examples for this and
the service works well with both of them, so I'd be happy to see more
people considering its use in the future. The first release is planned
for October or the beginning of November, so stay tuned!

Cheers,
Jannis

(P.S.: Please let us know if you think the specification is missing
 anything crucial. We're keen on making it better.)

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Philip Van Hoof
In reply to this post by Rob Taylor-3
On Mon, 2009-10-19 at 16:20 +0100, Rob Taylor wrote:

> We already have a thumbnailing service that is only just now starting to
> be used. A complete reimplementation of soemthing existing will not be a
> very useful thing. I also suggest that 13weeks for your entire plan is
> very over optimistic. I would suggest a better option would be to do a
> library with optimised thumbnailing routines. This would also be very
> useful for existng projects and probably result in you code being used
> in a number of situations.

> To add complexity you could also branch out
> into making thumbnail clips for videos. If you write up such a plan
> completely, i think you'd find it's more than enough work for a 13 week
> project.

Agree that a video thumbnailer would be very useful. However, we're
already developing (/ hopefully this week finishing) a video thumbnailer
that implements the 'specialized thumbnailer' spec (spec is available on
the page that Mark mentioned).

http://live.gnome.org/ThumbnailerSpec

Code can be found here (again, this week it'll receive some improve-
ments). This will likely also be the video thumbnailer that will make
thumbnails for videos on Harmattan devices.

http://maemo.gitorious.org/maemo-af/maemo-video-thumbnailer

A *very* useful thumbnailer for Maemo Harmattan would be a PDF one that
doesn't link with gdkpixbuf.

At the Maemo conference in Amsterdam I spoke with one of the KOffice
guys. He told me that there's some interest in making thumbnailers for
all of the formats that KOffice supports. Probably using Qt C++.

We're doing all this thumbnailing stuff in the open, you can find
feature branches for Tumbler's integration into Harmattan here:

http://maemo.gitorious.org/maemo-af/tumbler

Among the branches you'll find work that removes usage of GdkPixbuf. The
reason for that is that on Harmattan all GdkPixbuf usage is being
replaced with libquill. You can find the libquill project here:

http://maemo.gitorious.org/maemo-image-editor

That libquill library still depends on qtimagefilter which might be hard
for some people to get (there's an opensource release of it somewhere,
but it ain't easy to get this stuff installed). This week will the
libquill people work on refactoring-away this dependency (they told me).

(Quill is a different project, I wont go further into it)

You can find upstream Tumbler at the XFCE project. We're trying very
hard to ensure that each feature and change introduced for Maemo
Harmattan goes into the upstream project. Jannis Pohlmann is the XFCE
developer responsible for the upstream Tumbler project.

http://git.xfce.org/apps/tumbler/

Key features (on Maemo Harmattan, most/all are in upstream too):

o. Two schedulers each having their own queue: Background and
   foreground. The background one is set to SCHED_IDLE and uses
   IOPRIO_CLASS_IDLE for I/O priorities.
o. DBus signals are emitted with dbus_message_set_destination to avoid
   DBus traffic waking up processes needlessly
o. Ready and Error in case of foreground are emitted immediately
o. Ready and Error in case of background are emitted in group
o. Unqueue also cancels I/O operations
o. The mount-pre-unmount cancels I/O operations in case I/O takes place
   on the device being unmounted
o. Abstracted cache (makes it possible to implement your own thumbnail
   cache, although we probably wont use this on Maemo)
o. In Maemo we store JPEG instead of PNG (PNG is ~ braindead for this,
   as often are thumbnails in PNG of a JPEG larger and slower to load as
   the original JPEG)
o. The libquill library for rescaling large images rapidly
o. We'll ship with a specialized video thumbnailer that uses GStreamer
o. etc


--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Bugzilla from markg85@gmail.com
In reply to this post by Rob Taylor-3
Hi,

Let me say this again. (said it but apparently not clear)
I am currently in a school semester which takes roughly 3 weeks till
that one is done.
Then the next semester starts (and each semester takes 10 weeks) which
is the thumbnailing service semester.
So i only have 10 weeks not 13.
of those 10 weeks the first 8 are actual making, designing, and
documenting. the last 2 weeks are assessment and bug fixing when
needed.

So, i have __8__ weeks not 13.

For the complexity. What i described above is WAY to much for 8 weeks
(or 10 or 13) but those are for some part wishes (like OpenCL
inclusion, Cairo, pixbuf pointer passing).
The bare essentials are to make a (simple) service with some
functionality, make a plugin architecture, make plugins, optimize it
and "done"... (that includes c++ methods like inheritance, overloading
and making use of data structures like queue and stack but that's easy
since i already did that in my performance benchmark as listed in my
post (image).

And to clear up a misunderstanding about the idea. The idea is set
now, it has been approved and now it HAS to be made. i can not switch
ideas anymore. what i described in my first post if what is going to
be submitted on school at the ens of the next semester. I can focus
more on performance and plugins (like a video plugin) and leave the
daemon for what it is (nothing) till far in the project since i'm in
command of my own project.. just as long as the promised pieces get
submitted in "quality".

For Jannis and Philip,
Nice tumbler talk but could you two make suggestions for my project? ^_^

On Mon, Oct 19, 2009 at 5:20 PM, Rob Taylor <[hidden email]> wrote:

> Hi Mark,
>
> We already have a thumbnailing service that is only just now starting to
> be used. A complete reimplementation of soemthing existing will not be a
> very useful thing. I also suggest that 13weeks for your entire plan is
> very over optimistic. I would suggest a better option would be to do a
> library with optimised thumbnailing routines. This would also be very
> useful for existng projects and probably result in you code being used
> in a number of situations. To add complexity you could also branch out
> into making thumbnail clips for videos. If you write up such a plan
> completely, i think you'd find it's more than enough work for a 13 week
> project.
>
> Thanks,
> Rob
>
> Mark wrote:
>> Hi,
>>
>> on school i study Computer Science. That exists of a dozen "Major"
>> semesters and a few "Minor" semesters. Each lasts 10 weeks and that
>> for 3 years.
>> So this project, described in depth below, will have to be done within
>> 10 school weeks of which the first 8 are the "creation" weeks. After
>> that it gets rated by my teachers and i either pass or fail it.
>> Now on school i want to learn the following coding methods in a Minor
>> part. A minor is a part where i "can" compose my own semester and i
>> did it with the following "demands" as in methods i want to learn in
>> that semester:
>>
>> •       Plugin architecture
>> •       Asynchronous
>> •       Multi-threaded
>> •       Design patterns
>> •       Data structures (hash, queue, stack etc...)
>>
>> And the methods that will be in it but already "known" to me
>>
>> •       Daemon
>> •       IPC (D-Bus)
>>
>> Now i've read the wish on this list to make a thumbnailing service for
>> a generic central way to generate thumbnails.
>> All of the above methods can be used in a thumbnailing service. So, i
>> made a proposal on school to make just that, a thumbnailing service
>> with a plugin architecture.
>>
>> Is this been done before?
>> -------------------------
>> Well, not done before but a group of people is doing it as we speak:
>> http://live.gnome.org/ThumbnailerSpec ... i mailed them roughly this
>> mail a week ago to see if we could work together on this but i sadly
>> had to conclude that their project is in the final stages before release
>> 1 so there would only be documenting and bug fixing. That is also part
>> of my semester but not the only part. I want to learn more then just
>> bug hunting and documentation stuff and for that there is no room in
>> their project thus i ended up concluding that i can't join them for the
>> simple fact that my school would probably not allow that as a project.
>>
>> So, in roughly 13 weeks time (3 weeks in the current semester then the
>> 10 weeks for this project) the Gnome community will have the ability to
>> choose between 2 thumbnailing services. That is not a maybe but a
>> certainty. Why? Well, i made this proposal on school, it got approved so
>> now i simply have to make it in order to pass the semester.
>>
>> Will i be compatible with their dbus thumbnailing spec? Perhaps..
>> perhaps not. I do need to design the project before i start making the
>> actual code (major part of the project) but i do not know if i will
>> stick to the dbus rules they made. I can see some problems coming there
>> if you have huge folders to thumbnail that flood dbus.. O well, time
>> tell the answer to this.
>>
>> Thumbnailing service
>> -------------------------
>> The idea in short is:
>> The daemon holds the plugin framework and knows how to handle certain
>> things (to be determined) defined by class templates and interfaces.
>> A plugin can then for example say something like this (in readable
>> language instead of code):
>> "Hey, i'm the FFMPEG plugin and i can handle the following extensions
>> <<long list of extensions>>"
>> Plugins should be placed in a folder after which a daemon update
>> (through dbus?) should be executed to load and activate the plugins.
>>
>> So, what you get with this is a thumbnailing service that has plugins
>> (the pure service only holds the plugin architecture and lists from
>> extensions to plugins provided by the plugins).
>> That also means there will be a pixbuf plugin to read the default glib
>> images. (more on this one later after optimizing)
>>
>> Another thing which i see as needed but is not part of this school
>> project is making a allowed/denied list in the daemon that contains
>> the extensions allowed to thumbnail besides the extensions available to
>> make thumbnails from. The idea is that you tell the thumbnailing daemon
>> through dbus or by reading gconf keys which extensions are allowed
>> (or not allowed).
>>
>> Then for the dbus part. The idea is to let a application (for example
>> nautilus) request the thumbnails from their full scale file paths.
>> then the daemon should return the new file path to the thumbnails. That
>> is one way but could potential be a issue with folders that contain
>> thousands of files.
>>
>> Another way to do this is: let nautilus send the folder that needs to
>> be thumbnailed. then the daemon should read the folder, check if a
>> thumbnail already exists and make it if not. The daemon should then
>> (as long as it's busy) send updates (let’s say every 0.1 second) to
>> nautilus with the files that have been thumbnailed.
>>
>> What probably might be a better idea is to let nautilus look in the
>> folder and see which files need to be thumbnailed instead of handling
>> that task to the daemon. Then nautilus can send the list of files that
>> need to be thumbnailed to the daemon.
>>
>> Yet another possible way where i have no clue if it's possible is
>> making a file list hash (or map or vector or. anything) in nautilus that
>> contains the files that needs to be thumbnailed. Nautilus should filter
>> out the ones that are already thumbnailed. Then the pointer of that hash
>> (let’s call it a hash for now) should be send to the thumbnailing daemon
>> where the thumbnails are being made and returned in another hash
>> (also provided by nautilus). I have no idea if this is for one even
>> possible and if it's wise to just pointers from one app to another.
>> If this gets to complex for the scope of this school project then the
>> simple solution (aka the first method) will be used.
>>
>> The intention (and requirement) is to make this daemon asynchronous so
>> it won't block if another application suddenly wants to request
>> thumbnails.
>>
>> Optimizing
>> -------------------------
>> Since the project didn't seem complex enough on paper (can you believe
>> that!) i was forced to add one more thing. Luckily i already wanted to
>> do something with optimizing in Gnome/glib so i added it to the paper.
>>
>> The idea with the optimizing is making the thumbnail generation as
>> fast as possible! If you've been reading the gtk devel list lately you
>> must have noticed that i already did quite a lot to make thumbnail
>> generation as fast as possible. The latest benchmark so far:
>> http://img36.imageshack.us/i/scalingperformance.png/
>> which shows a significant speed improvement when using threaded
>> thumbnailing. This mean that the intended optimizing part is already
>> partly done but could be improved more by using threaded thumbnailing
>> with gnome_thumbnail_scale_down_pixbuff in combination with
>> gdk_pixbuff_new_from_file_at_scale.
>>
>> About the image; with the 70 seconds bar my cpu cores (4) ran at 40%
>> each and i had "50%" iowait in iostat. The 21 seconds is when the
>> images are cached then all cores ran at 100% resulting at 21 seconds.
>> The benchmarks are all done with the bilinear flag set where possible
>> for the best quality thumbnails.
>>
>> When that's working in the daemon it might be possible to speed up the
>> rendering of the thumbnails in nautilus (the gtk part of it) by batch
>> rendering the available thumbnails if that's not done already. Let’s say
>> a nautilus redraw every 0.2 seconds till all thumbnails are visible.
>>
>> There are more optimiz ways like using OpenCL or Cairo! more about them
>> just below.
>>
>> GdkPixbuf? Cairo? OpenCL?
>> -------------------------
>> First GdkPixbuf. I have been told that the current GdkPixbuf "sucks" and
>> should probably be avoided when attempting to make thumbnails as fast
>> as possible. One of the reasons to avoid it where Cairo. If i wanted to
>> have hardware accelerated downscaling i first need to make a Cairo
>> object and from there i need to make a Xlib object. Then i can save it
>> with cairo but only in .png and i personally want to be able to pick
>> JPEG2000 and JPEG as well. Now i have been told that only the steps of
>> converting a GdkPixbuf to a Xlib object could take so long that there is
>> hardly speed to gain there. So for that i would have to avoid GdkPixbuf
>> and take a more direct aproach. Note that this does fall outside the
>> scope of this school project but it would just be nice to have.
>>
>> As for OpenCl. I am havily in favor of that method but my hardware
>> configuration is sadly the most horrible one to choose. Intel CPU
>> and nvidia GPU. there are no stable releases for the GPU yet on linux
>> and for the CPU there isn't a driver so i have no OpenCL options.
>> However if this becomes possible during my project i will certainly
>> attempt to implement it.
>>
>> Repository?
>> -------------------------
>> I would love to have a repository for this on the Gnome servers. Would
>> that be possible? it would be my first ever GIT repo. If this is not
>> going to be allowed then it's either going to be a github, gitorious or
>> google code repository. The code will be publicly available with the
>> GPL (v2 or v3) license.
>>
>> Blog or Log?
>> -------------------------
>> I also would like to make daily or weekly posts of the progress. I can
>> do that on my own blog but would it then be allowed that my blog is
>> readable on planet gtk or planet gnome (or both)?
>>
>> Gnome subdomain?
>> -------------------------
>> If the Repository can't be with gnome i will probably just use my site
>> whatever those other 3 repo providers offer. But i would like to have
>> a gnome sub domain for example: thumbnailing-service.gnome.org or some
>> other name (i still have to make up a name for this project).
>>
>> Conclusion
>> -------------------------
>> As said there was the wish to make this. I made this proposal on
>> school and it got accepted. This means i __have__ to make it now.
>> That's a risk but in the worst case scenario i just gain knowledge with
>> the methods above. In reality i hope this to be useful and perhaps even
>> viable for inclusion in Gnome. It might result in a rewrite to be good
>> enough for gnome ^_^. My intention certainly is to make it usable in
>> gnome whether that is as just a app of mine or a app distributed with
>> every new gnome release.. the latter option would be the best one.
>>
>> The approved school document
>> -------------------------
>> I sadly can't give it. It's written in dutch. If you are dutch or want
>> to translate it to english you can get it. It's 12 pages of which 3 are
>> scheduling pages which can be trashed. The text in this mail describes
>> it more in depth then the approved document since that needed to be
>> "general".
>>
>> Feedback
>> -------------------------
>> I hope some people could post their opinions about this, where can
>> more optimizing things be done that fall in this scope, did i miss
>> features for the thumbnialing service? etc.. etc.. Your feedback would
>> be greatly appreciated.
>>
>> Thanx a lot for reading this long mail,
>> Mark
>> _______________________________________________
>> gtk-devel-list mailing list
>> [hidden email]
>> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
> --
> Rob Taylor, Codethink Ltd. - http://codethink.co.uk
>
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

RE: Thumbnailing service project; opinions, suggestions?

sbaka
Hi Mark,

It sounds like you are going to do, what you are going to do, and though it is of great benefit to you, I suppose I would ask the questions (in agreement with the last post on this):

1) how does this improve the current development track at least for thumbnail generation? There seems to be more than one project already way ahead of the game on this, so developing something for school is great, but including it in the tree would simply add bulk not functionality IMHO (were not talking about anything new). Can you alliterate how you believe this better then what is out there already?

2) Will 8 weeks be enough, even for the most basic of module? It may work, but then what? I have written plenty of code that works, but is far from being any kind of general purpose tool in a library, there are requirements and generalizations, that I simply do not see being addressed in an 8 week project for school, again just MHO.

3) C++ ???  Again, please forgive me for my ignorance, but I though the library is in Objective-C, quite different from C++. It is true that it has been written in an Object oriented way, but I think trying to write a heavily used component like the thumbnail module, using C++ is going to result in much bloat, and is contrary to the statement "GTK+ it is written in C, but has bindings to many other popular programming languages such as C++, Python and C# among others."

In general, and this is my kudos to the GTK team, other then on the OS X platform missing a few features (which I am now using), the performance, feature richness, and stability has been outstanding. I only wish more of the IGE stuff was fixed, and as soon as I get past this development cycle 75 days to the implementation on 010110, hopefully I will know enough about the library and Mac OS X to contribute in some small way to that part of it.

Having said all that, it is a great exercise, and as a learning experience it will serve you well, however, and I am a nobody so the GTK team may think differently, I would say it does not benefit the project as a separate track / tree, and I would seriously look at the work you have cut out for yourself in 8 weeks, this is heavy stuff.

As French is the language of love, so C is the language of my heart!
Shawn

P.S really it was the whole mention of C++ that got me going LOL


i'm EMAILING FOR THE GREATER GOOD
Join me


> Date: Mon, 19 Oct 2009 21:35:10 +0200
> Subject: Re: Thumbnailing service project; opinions, suggestions?
> From: [hidden email]
> To: [hidden email]
> CC: [hidden email]
>
> Hi,
>
> Let me say this again. (said it but apparently not clear)
> I am currently in a school semester which takes roughly 3 weeks till
> that one is done.
> Then the next semester starts (and each semester takes 10 weeks) which
> is the thumbnailing service semester.
> So i only have 10 weeks not 13.
> of those 10 weeks the first 8 are actual making, designing, and
> documenting. the last 2 weeks are assessment and bug fixing when
> needed.
>
> So, i have __8__ weeks not 13.
>
> For the complexity. What i described above is WAY to much for 8 weeks
> (or 10 or 13) but those are for some part wishes (like OpenCL
> inclusion, Cairo, pixbuf pointer passing).
> The bare essentials are to make a (simple) service with some
> functionality, make a plugin architecture, make plugins, optimize it
> and "done"... (that includes c++ methods like inheritance, overloading
> and making use of data structures like queue and stack but that's easy
> since i already did that in my performance benchmark as listed in my
> post (image).
>
> And to clear up a misunderstanding about the idea. The idea is set
> now, it has been approved and now it HAS to be made. i can not switch
> ideas anymore. what i described in my first post if what is going to
> be submitted on school at the ens of the next semester. I can focus
> more on performance and plugins (like a video plugin) and leave the
> daemon for what it is (nothing) till far in the project since i'm in
> command of my own project.. just as long as the promised pieces get
> submitted in "quality".
>
> For Jannis and Philip,
> Nice tumbler talk but could you two make suggestions for my project? ^_^
>
> On Mon, Oct 19, 2009 at 5:20 PM, Rob Taylor <[hidden email]> wrote:
> > Hi Mark,
> >
> > We already have a thumbnailing service that is only just now starting to
> > be used. A complete reimplementation of soemthing existing will not be a
> > very useful thing. I also suggest that 13weeks for your entire plan is
> > very over optimistic. I would suggest a better option would be to do a
> > library with optimised thumbnailing routines. This would also be very
> > useful for existng projects and probably result in you code being used
> > in a number of situations. To add complexity you could also branch out
> > into making thumbnail clips for videos. If you write up such a plan
> > completely, i think you'd find it's more than enough work for a 13 week
> > project.
> >
> > Thanks,
> > Rob
> >
> > Mark wrote:
> >> Hi,
> >>
> >> on school i study Computer Science. That exists of a dozen "Major"
> >> semesters and a few "Minor" semesters. Each lasts 10 weeks and that
> >> for 3 years.
> >> So this project, described in depth below, will have to be done within
> >> 10 school weeks of which the first 8 are the "creation" weeks. After
> >> that it gets rated by my teachers and i either pass or fail it.
> >> Now on school i want to learn the following coding methods in a Minor
> >> part. A minor is a part where i "can" compose my own semester and i
> >> did it with the following "demands" as in methods i want to learn in
> >> that semester:
> >>
> >> •       Plugin architecture
> >> •       Asynchronous
> >> •       Multi-threaded
> >> •       Design patterns
> >> •       Data structures (hash, queue, stack etc...)
> >>
> >> And the methods that will be in it but already "known" to me
> >>
> >> •       Daemon
> >> •       IPC (D-Bus)
> >>
> >> Now i've read the wish on this list to make a thumbnailing service for
> >> a generic central way to generate thumbnails.
> >> All of the above methods can be used in a thumbnailing service. So, i
> >> made a proposal on school to make just that, a thumbnailing service
> >> with a plugin architecture.
> >>
> >> Is this been done before?
> >> -------------------------
> >> Well, not done before but a group of people is doing it as we speak:
> >> http://live.gnome.org/ThumbnailerSpec ... i mailed them roughly this
> >> mail a week ago to see if we could work together on this but i sadly
> >> had to conclude that their project is in the final stages before release
> >> 1 so there would only be documenting and bug fixing. That is also part
> >> of my semester but not the only part. I want to learn more then just
> >> bug hunting and documentation stuff and for that there is no room in
> >> their project thus i ended up concluding that i can't join them for the
> >> simple fact that my school would probably not allow that as a project.
> >>
> >> So, in roughly 13 weeks time (3 weeks in the current semester then the
> >> 10 weeks for this project) the Gnome community will have the ability to
> >> choose between 2 thumbnailing services. That is not a maybe but a
> >> certainty. Why? Well, i made this proposal on school, it got approved so
> >> now i simply have to make it in order to pass the semester.
> >>
> >> Will i be compatible with their dbus thumbnailing spec? Perhaps..
> >> perhaps not. I do need to design the project before i start making the
> >> actual code (major part of the project) but i do not know if i will
> >> stick to the dbus rules they made. I can see some problems coming there
> >> if you have huge folders to thumbnail that flood dbus.. O well, time
> >> tell the answer to this.
> >>
> >> Thumbnailing service
> >> -------------------------
> >> The idea in short is:
> >> The daemon holds the plugin framework and knows how to handle certain
> >> things (to be determined) defined by class templates and interfaces.
> >> A plugin can then for example say something like this (in readable
> >> language instead of code):
> >> "Hey, i'm the FFMPEG plugin and i can handle the following extensions
> >> <<long list of extensions>>"
> >> Plugins should be placed in a folder after which a daemon update
> >> (through dbus?) should be executed to load and activate the plugins.
> >>
> >> So, what you get with this is a thumbnailing service that has plugins
> >> (the pure service only holds the plugin architecture and lists from
> >> extensions to plugins provided by the plugins).
> >> That also means there will be a pixbuf plugin to read the default glib
> >> images. (more on this one later after optimizing)
> >>
> >> Another thing which i see as needed but is not part of this school
> >> project is making a allowed/denied list in the daemon that contains
> >> the extensions allowed to thumbnail besides the extensions available to
> >> make thumbnails from. The idea is that you tell the thumbnailing daemon
> >> through dbus or by reading gconf keys which extensions are allowed
> >> (or not allowed).
> >>
> >> Then for the dbus part. The idea is to let a application (for example
> >> nautilus) request the thumbnails from their full scale file paths.
> >> then the daemon should return the new file path to the thumbnails. That
> >> is one way but could potential be a issue with folders that contain
> >> thousands of files.
> >>
> >> Another way to do this is: let nautilus send the folder that needs to
> >> be thumbnailed. then the daemon should read the folder, check if a
> >> thumbnail already exists and make it if not. The daemon should then
> >> (as long as it's busy) send updates (let’s say every 0.1 second) to
> >> nautilus with the files that have been thumbnailed.
> >>
> >> What probably might be a better idea is to let nautilus look in the
> >> folder and see which files need to be thumbnailed instead of handling
> >> that task to the daemon. Then nautilus can send the list of files that
> >> need to be thumbnailed to the daemon.
> >>
> >> Yet another possible way where i have no clue if it's possible is
> >> making a file list hash (or map or vector or. anything) in nautilus that
> >> contains the files that needs to be thumbnailed. Nautilus should filter
> >> out the ones that are already thumbnailed. Then the pointer of that hash
> >> (let’s call it a hash for now) should be send to the thumbnailing daemon
> >> where the thumbnails are being made and returned in another hash
> >> (also provided by nautilus). I have no idea if this is for one even
> >> possible and if it's wise to just pointers from one app to another.
> >> If this gets to complex for the scope of this school project then the
> >> simple solution (aka the first method) will be used.
> >>
> >> The intention (and requirement) is to make this daemon asynchronous so
> >> it won't block if another application suddenly wants to request
> >> thumbnails.
> >>
> >> Optimizing
> >> -------------------------
> >> Since the project didn't seem complex enough on paper (can you believe
> >> that!) i was forced to add one more thing. Luckily i already wanted to
> >> do something with optimizing in Gnome/glib so i added it to the paper.
> >>
> >> The idea with the optimizing is making the thumbnail generation as
> >> fast as possible! If you've been reading the gtk devel list lately you
> >> must have noticed that i already did quite a lot to make thumbnail
> >> generation as fast as possible. The latest benchmark so far:
> >> http://img36.imageshack.us/i/scalingperformance.png/
> >> which shows a significant speed improvement when using threaded
> >> thumbnailing. This mean that the intended optimizing part is already
> >> partly done but could be improved more by using threaded thumbnailing
> >> with gnome_thumbnail_scale_down_pixbuff in combination with
> >> gdk_pixbuff_new_from_file_at_scale.
> >>
> >> About the image; with the 70 seconds bar my cpu cores (4) ran at 40%
> >> each and i had "50%" iowait in iostat. The 21 seconds is when the
> >> images are cached then all cores ran at 100% resulting at 21 seconds.
> >> The benchmarks are all done with the bilinear flag set where possible
> >> for the best quality thumbnails.
> >>
> >> When that's working in the daemon it might be possible to speed up the
> >> rendering of the thumbnails in nautilus (the gtk part of it) by batch
> >> rendering the available thumbnails if that's not done already. Let’s say
> >> a nautilus redraw every 0.2 seconds till all thumbnails are visible.
> >>
> >> There are more optimiz ways like using OpenCL or Cairo! more about them
> >> just below.
> >>
> >> GdkPixbuf? Cairo? OpenCL?
> >> -------------------------
> >> First GdkPixbuf. I have been told that the current GdkPixbuf "sucks" and
> >> should probably be avoided when attempting to make thumbnails as fast
> >> as possible. One of the reasons to avoid it where Cairo. If i wanted to
> >> have hardware accelerated downscaling i first need to make a Cairo
> >> object and from there i need to make a Xlib object. Then i can save it
> >> with cairo but only in .png and i personally want to be able to pick
> >> JPEG2000 and JPEG as well. Now i have been told that only the steps of
> >> converting a GdkPixbuf to a Xlib object could take so long that there is
> >> hardly speed to gain there. So for that i would have to avoid GdkPixbuf
> >> and take a more direct aproach. Note that this does fall outside the
> >> scope of this school project but it would just be nice to have.
> >>
> >> As for OpenCl. I am havily in favor of that method but my hardware
> >> configuration is sadly the most horrible one to choose. Intel CPU
> >> and nvidia GPU. there are no stable releases for the GPU yet on linux
> >> and for the CPU there isn't a driver so i have no OpenCL options.
> >> However if this becomes possible during my project i will certainly
> >> attempt to implement it.
> >>
> >> Repository?
> >> -------------------------
> >> I would love to have a repository for this on the Gnome servers. Would
> >> that be possible? it would be my first ever GIT repo. If this is not
> >> going to be allowed then it's either going to be a github, gitorious or
> >> google code repository. The code will be publicly available with the
> >> GPL (v2 or v3) license.
> >>
> >> Blog or Log?
> >> -------------------------
> >> I also would like to make daily or weekly posts of the progress. I can
> >> do that on my own blog but would it then be allowed that my blog is
> >> readable on planet gtk or planet gnome (or both)?
> >>
> >> Gnome subdomain?
> >> -------------------------
> >> If the Repository can't be with gnome i will probably just use my site
> >> whatever those other 3 repo providers offer. But i would like to have
> >> a gnome sub domain for example: thumbnailing-service.gnome.org or some
> >> other name (i still have to make up a name for this project).
> >>
> >> Conclusion
> >> -------------------------
> >> As said there was the wish to make this. I made this proposal on
> >> school and it got accepted. This means i __have__ to make it now.
> >> That's a risk but in the worst case scenario i just gain knowledge with
> >> the methods above. In reality i hope this to be useful and perhaps even
> >> viable for inclusion in Gnome. It might result in a rewrite to be good
> >> enough for gnome ^_^. My intention certainly is to make it usable in
> >> gnome whether that is as just a app of mine or a app distributed with
> >> every new gnome release.. the latter option would be the best one.
> >>
> >> The approved school document
> >> -------------------------
> >> I sadly can't give it. It's written in dutch. If you are dutch or want
> >> to translate it to english you can get it. It's 12 pages of which 3 are
> >> scheduling pages which can be trashed. The text in this mail describes
> >> it more in depth then the approved document since that needed to be
> >> "general".
> >>
> >> Feedback
> >> -------------------------
> >> I hope some people could post their opinions about this, where can
> >> more optimizing things be done that fall in this scope, did i miss
> >> features for the thumbnialing service? etc.. etc.. Your feedback would
> >> be greatly appreciated.
> >>
> >> Thanx a lot for reading this long mail,
> >> Mark
> >> _______________________________________________
> >> gtk-devel-list mailing list
> >> [hidden email]
> >> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
> >
> > --
> > Rob Taylor, Codethink Ltd. - http://codethink.co.uk
> >
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Bugzilla from markg85@gmail.com


On Tue, Oct 20, 2009 at 1:18 AM, Shawn Bakhtiar <[hidden email]> wrote:
Hi Mark,
Hi

It sounds like you are going to do, what you are going to do, and though it is of great benefit to you, I suppose I would ask the questions (in agreement with the last post on this):

1) how does this improve the current development track at least for thumbnail generation? There seems to be more than one project already way ahead of the game on this, so developing something for school is great, but including it in the tree would simply add bulk not functionality IMHO (were not talking about anything new). Can you alliterate how you believe this better then what is out there already?
To be honest i expect it to an extremely simplified version of tumbler that serves only one purpose: learning new things. Other then that i might do it completely different which might result in a way better (or worse) thumbnailing daemon. My work is probably going to be defined by it's simplicity. I really don't know yet how complex it is going to be or how simple but it will certainly _not_ have the features that tumbler has. It probably will only have one or 2 plugins.. one for pixbuf and one for something else.

2) Will 8 weeks be enough, even for the most basic of module? It may work, but then what? I have written plenty of code that works, but is far from being any kind of general purpose tool in a library, there are requirements and generalizations, that I simply do not see being addressed in an 8 week project for school, again just MHO.
It will probably of the level: "it works" but will lack a lot and will likely not be safe to use, has memory leaks all over the place and things like that.

3) C++ ???  Again, please forgive me for my ignorance, but I though the library is in Objective-C, quite different from C++. It is true that it has been written in an Object oriented way, but I think trying to write a heavily used component like the thumbnail module, using C++ is going to result in much bloat, and is contrary to the statement "GTK+ it is written in C, but has bindings to many other popular programming languages such as C++, Python and C# among others."
C++ as in what i design is going to be in classes. In those classes i will use glib's C functions and not glibmm. I simply use C where possible and use C++ for my own objects.

In general, and this is my kudos to the GTK team, other then on the OS X platform missing a few features (which I am now using), the performance, feature richness, and stability has been outstanding. I only wish more of the IGE stuff was fixed, and as soon as I get past this development cycle 75 days to the implementation on 010110, hopefully I will know enough about the library and Mac OS X to contribute in some small way to that part of it.

Having said all that, it is a great exercise, and as a learning experience it will serve you well, however, and I am a nobody so the GTK team may think differently, I would say it does not benefit the project as a separate track / tree, and I would seriously look at the work you have cut out for yourself in 8 weeks, this is heavy stuff.
This really is just for learning purposes.. i can steer it in a certain direction but the outline is set. The requirements are there.. now it's up to me to fill it in and make it happen.
And now that i know of the tumbler project i also do think that there will be no benefit for gnome to have this in a separate tree.. it would be nice though :) Also the ability to choose between thumbnailers isn't bad.. this is opensource after all and that's all about freedom of choice.

As French is the language of love, so C is the language of my heart!
Shawn

P.S really it was the whole mention of C++ that got me going LOL


i'm EMAILING FOR THE GREATER GOOD
Join me


> Date: Mon, 19 Oct 2009 21:35:10 +0200
> Subject: Re: Thumbnailing service project; opinions, suggestions?
> From: [hidden email]
> To: [hidden email]
> CC: [hidden email]

>
> Hi,
>
> Let me say this again. (said it but apparently not clear)
> I am currently in a school semester which takes roughly 3 weeks till
> that one is done.
> Then the next semester starts (and each semester takes 10 weeks) which
> is the thumbnailing service semester.
> So i only have 10 weeks not 13.
> of those 10 weeks the first 8 are actual making, designing, and
> documenting. the last 2 weeks are assessment and bug fixing when
> needed.
>
> So, i have __8__ weeks not 13.
>
> For the complexity. What i described above is WAY to much for 8 weeks
> (or 10 or 13) but those are for some part wishes (like OpenCL
> inclusion, Cairo, pixbuf pointer passing).
> The bare essentials are to make a (simple) service with some
> functionality, make a plugin architecture, make plugins, optimize it
> and "done"... (that includes c++ methods like inheritance, overloading
> and making use of data structures like queue and stack but that's easy
> since i already did that in my performance benchmark as listed in my
> post (image).
>
> And to clear up a misunderstanding about the idea. The idea is set
> now, it has been approved and now it HAS to be made. i can not switch
> ideas anymore. what i described in my first post if what is going to
> be submitted on school at the ens of the next semester. I can focus
> more on performance and plugins (like a video plugin) and leave the
> daemon for what it is (nothing) till far in the project since i'm in
> command of my own project.. just as long as the promised pieces get
> submitted in "quality".
>
> For Jannis and Philip,
> Nice tumbler talk but could you two make suggestions for my project? ^_^
>
> On Mon, Oct 19, 2009 at 5:20 PM, Rob Taylor <[hidden email]> wrote:
> > Hi Mark,
> >
> > We already have a thumbnailing service that is only just now starting to
> > be used. A complete reimplementation of soemthing existing will not be a
> > very useful thing. I also suggest that 13weeks for your entire plan is
> > very over optimistic. I would suggest a better option would be to do a
> > library with optimised thumbnailing routines. This would also be very
> > useful for existng projects and probably result in you code being used
> > in a number of situations. To add complexity you could also branch out
> > into making thumbnail clips for videos. If you write up such a plan
> > completely, i think you'd find it's more than enough work for a 13 week
> > project.
> >
> > Thanks,
> > Rob
> >
> > Mark wrote:
> >> Hi,
> >>
> >> on school i study Computer Science. That exists of a dozen "Major"
> >> semesters and a few "Minor" semesters. Each lasts 10 weeks and that
> >> for 3 years.
> >> So this project, described in depth below, will have to be done within
> >> 10 school weeks of which the first 8 are the "creation" weeks. After
> >> that it gets rated by my teachers and i either pass or fail it.
> >> Now on school i want to learn the following coding methods in a Minor
> >> part. A minor is a part where i "can" compose my own semester and i
> >> did it with the following "demands" as in methods i want to learn in
> >> that semester:
> >>
> >> •       Plugin architecture
> >> •       Asynchronous
> >> •       Multi-threaded
> >> •       Design patterns
> >> •       Data structures (hash, queue, stack etc...)
> >>
> >> And the methods that will be in it but already "known" to me
> >>
> >> •       Daemon
> >> •       IPC (D-Bus)
> >>
> >> Now i've read the wish on this list to make a thumbnailing service for
> >> a generic central way to generate thumbnails.
> >> All of the above methods can be used in a thumbnailing service. So, i
> >> made a proposal on school to make just that, a thumbnailing service
> >> with a plugin architecture.
> >>
> >> Is this been done before?
> >> -------------------------
> >> Well, not done before but a group of people is doing it as we speak:
> >> http://live.gnome.org/ThumbnailerSpec ... i mailed them roughly this
> >> mail a week ago to see if we could work together on this but i sadly
> >> had to conclude that their project is in the final stages before release
> >> 1 so there would only be documenting and bug fixing. That is also part
> >> of my semester but not the only part. I want to learn more then just
> >> bug hunting and documentation stuff and for that there is no room in
> >> their project thus i ended up concluding that i can't join them for the
> >> simple fact that my school would probably not allow that as a project.
> >>
> >> So, in roughly 13 weeks time (3 weeks in the current semester then the
> >> 10 weeks for this project) the Gnome community will have the ability to
> >> choose between 2 thumbnailing services. That is not a maybe but a
> >> certainty. Why? Well, i made this proposal on school, it got approved so
> >> now i simply have to make it in order to pass the semester.
> >>
> >> Will i be compatible with their dbus thumbnailing spec? Perhaps..
> >> perhaps not. I do need to design the project before i start making the
> >> actual code (major part of the project) but i do not know if i will
> >> stick to the dbus rules they made. I can see some problems coming there
> >> if you have huge folders to thumbnail that flood dbus.. O well, time
> >> tell the answer to this.
> >>
> >> Thumbnailing service
> >> -------------------------
> >> The idea in short is:
> >> The daemon holds the plugin framework and knows how to handle certain
> >> things (to be determined) defined by class templates and interfaces.
> >> A plugin can then for example say something like this (in readable
> >> language instead of code):
> >> "Hey, i'm the FFMPEG plugin and i can handle the following extensions
> >> <<long list of extensions>>"
> >> Plugins should be placed in a folder after which a daemon update
> >> (through dbus?) should be executed to load and activate the plugins.
> >>
> >> So, what you get with this is a thumbnailing service that has plugins
> >> (the pure service only holds the plugin architecture and lists from
> >> extensions to plugins provided by the plugins).
> >> That also means there will be a pixbuf plugin to read the default glib
> >> images. (more on this one later after optimizing)
> >>
> >> Another thing which i see as needed but is not part of this school
> >> project is making a allowed/denied list in the daemon that contains
> >> the extensions allowed to thumbnail besides the extensions available to
> >> make thumbnails from. The idea is that you tell the thumbnailing daemon
> >> through dbus or by reading gconf keys which extensions are allowed
> >> (or not allowed).
> >>
> >> Then for the dbus part. The idea is to let a application (for example
> >> nautilus) request the thumbnails from their full scale file paths.
> >> then the daemon should return the new file path to the thumbnails. That
> >> is one way but could potential be a issue with folders that contain
> >> thousands of files.
> >>
> >> Another way to do this is: let nautilus send the folder that needs to
> >> be thumbnailed. then the daemon should read the folder, check if a
> >> thumbnail already exists and make it if not. The daemon should then
> >> (as long as it's busy) send updates (let’s say every 0.1 second) to
> >> nautilus with the files that have been thumbnailed.
> >>
> >> What probably might be a better idea is to let nautilus look in the
> >> folder and see which files need to be thumbnailed instead of handling
> >> that task to the daemon. Then nautilus can send the list of files that
> >> need to be thumbnailed to the daemon.
> >>
> >> Yet another possible way where i have no clue if it's possible is
> >> making a file list hash (or map or vector or. anything) in nautilus that
> >> contains the files that needs to be thumbnailed. Nautilus should filter
> >> out the ones that are already thumbnailed. Then the pointer of that hash
> >> (let’s call it a hash for now) should be send to the thumbnailing daemon
> >> where the thumbnails are being made and returned in another hash
> >> (also provided by nautilus). I have no idea if this is for one even
> >> possible and if it's wise to just pointers from one app to another.
> >> If this gets to complex for the scope of this school project then the
> >> simple solution (aka the first method) will be used.
> >>
> >> The intention (and requirement) is to make this daemon asynchronous so
> >> it won't block if another application suddenly wants to request
> >> thumbnails.
> >>
> >> Optimizing
> >> -------------------------
> >> Since the project didn't seem complex enough on paper (can you believe
> >> that!) i was forced to add one more thing. Luckily i already wanted to
> >> do something with optimizing in Gnome/glib so i added it to the paper.
> >>
> >> The idea with the optimizing is making the thumbnail generation as
> >> fast as possible! If you've been reading the gtk devel list lately you
> >> must have noticed that i already did quite a lot to make thumbnail
> >> generation as fast as possible. The latest benchmark so far:
> >> http://img36.imageshack.us/i/scalingperformance.png/
> >> which shows a significant speed improvement when using threaded
> >> thumbnailing. This mean that the intended optimizing part is already
> >> partly done but could be improved more by using threaded thumbnailing
> >> with gnome_thumbnail_scale_down_pixbuff in combination with
> >> gdk_pixbuff_new_from_file_at_scale.
> >>
> >> About the image; with the 70 seconds bar my cpu cores (4) ran at 40%
> >> each and i had "50%" iowait in iostat. The 21 seconds is when the
> >> images are cached then all cores ran at 100% resulting at 21 seconds.
> >> The benchmarks are all done with the bilinear flag set where possible
> >> for the best quality thumbnails.
> >>
> >> When that's working in the daemon it might be possible to speed up the
> >> rendering of the thumbnails in nautilus (the gtk part of it) by batch
> >> rendering the available thumbnails if that's not done already. Let’s say
> >> a nautilus redraw every 0.2 seconds till all thumbnails are visible.
> >>
> >> There are more optimiz ways like using OpenCL or Cairo! more about them
> >> just below.
> >>
> >> GdkPixbuf? Cairo? OpenCL?
> >> -------------------------
> >> First GdkPixbuf. I have been told that the current GdkPixbuf "sucks" and
> >> should probably be avoided when attempting to make thumbnails as fast
> >> as possible. One of the reasons to avoid it where Cairo. If i wanted to
> >> have hardware accelerated downscaling i first need to make a Cairo
> >> object and from there i need to make a Xlib object. Then i can save it
> >> with cairo but only in .png and i personally want to be able to pick
> >> JPEG2000 and JPEG as well. Now i have been told that only the steps of
> >> converting a GdkPixbuf to a Xlib object could take so long that there is
> >> hardly speed to gain there. So for that i would have to avoid GdkPixbuf
> >> and take a more direct aproach. Note that this does fall outside the
> >> scope of this school project but it would just be nice to have.
> >>
> >> As for OpenCl. I am havily in favor of that method but my hardware
> >> configuration is sadly the most horrible one to choose. Intel CPU
> >> and nvidia GPU. there are no stable releases for the GPU yet on linux
> >> and for the CPU there isn't a driver so i have no OpenCL options.
> >> However if this becomes possible during my project i will certainly
> >> attempt to implement it.
> >>
> >> Repository?
> >> -------------------------
> >> I would love to have a repository for this on the Gnome servers. Would
> >> that be possible? it would be my first ever GIT repo. If this is not
> >> going to be allowed then it's either going to be a github, gitorious or
> >> google code repository. The code will be publicly available with the
> >> GPL (v2 or v3) license.
> >>
> >> Blog or Log?
> >> -------------------------
> >> I also would like to make daily or weekly posts of the progress. I can
> >> do that on my own blog but would it then be allowed that my blog is
> >> readable on planet gtk or planet gnome (or both)?
> >>
> >> Gnome subdomain?
> >> -------------------------
> >> If the Repository can't be with gnome i will probably just use my site
> >> whatever those other 3 repo providers offer. But i would like to have
> >> a gnome sub domain for example: thumbnailing-service.gnome.org or some
> >> other name (i still have to make up a name for this project).
> >>
> >> Conclusion
> >> -------------------------
> >> As said there was the wish to make this. I made this proposal on
> >> school and it got accepted. This means i __have__ to make it now.
> >> That's a risk but in the worst case scenario i just gain knowledge with
> >> the methods above. In reality i hope this to be useful and perhaps even
> >> viable for inclusion in Gnome. It might result in a rewrite to be good
> >> enough for gnome ^_^. My intention certainly is to make it usable in
> >> gnome whether that is as just a app of mine or a app distributed with
> >> every new gnome release.. the latter option would be the best one.
> >>
> >> The approved school document
> >> -------------------------
> >> I sadly can't give it. It's written in dutch. If you are dutch or want
> >> to translate it to english you can get it. It's 12 pages of which 3 are
> >> scheduling pages which can be trashed. The text in this mail describes
> >> it more in depth then the approved document since that needed to be
> >> "general".
> >>
> >> Feedback
> >> -------------------------
> >> I hope some people could post their opinions about this, where can
> >> more optimizing things be done that fall in this scope, did i miss
> >> features for the thumbnialing service? etc.. etc.. Your feedback would
> >> be greatly appreciated.
> >>
> >> Thanx a lot for reading this long mail,
> >> Mark
> >> _______________________________________________
> >> gtk-devel-list mailing list
> >> [hidden email]
> >> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
> >
> > --
> > Rob Taylor, Codethink Ltd. - http://codethink.co.uk
> >
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Richard Hughes-6
2009/10/20 Mark <[hidden email]>
> Also the ability to choose between thumbnailers isn't bad.. this is opensource after all and that's all about freedom of choice.

Something inside of me just died.

Richard.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Philip Van Hoof
In reply to this post by Bugzilla from markg85@gmail.com
On Mon, 2009-10-19 at 21:35 +0200, Mark wrote:

> For Jannis and Philip,
> Nice tumbler talk but could you two make suggestions for my project? ^_^

As I already wrote:

A PDF thumbnailer that implements the 'specialized thumbnailer' spec
that doesn't need to link with gdkpixbuf.

I think that matches your project description, it fits in the architec-
ture of Tumbler (and if done right we could make this a project that
many people will use and install alongside Tumbler).

It's much more simple than developing an entire thumbnailer, as you only
need to implement one D-Bus method called "Create".

- You'll have to work with a queue handling the thumbnailing, as Create
  isn't allowed to block, which means that GThreadQueue could for
  example be used (which means that your work will involve dealing with
  threads).

- You'll need to deal with DBus .service registration

- You'll need to code against a specification (which is in general
  harder than doing your own thing - but schools like that)

- It's a thumbnailer service and it could work standalone (which means
  that it fits your requirements for school)

- You wont have the NIH syndrome. Nobody has yet made a PDF thumbnailer
  that implements the 'specialized thumbnailer' spec

- It sounds doable within 8 weeks

I suggest that you set up a gitorious repository, start with making a
skeleton out of the maemo-video-thumbnailer project, adapt all the files
that you read about in the specification, hollow out the methods, and
then implement them for PDF files instead of video (GStreamer).

You can check out libpoppler for dealing with PDF files. Poppler can be
compiled not to use gdkpixbuf, but instead cairo as far as I know.

I strongly advise to do that.


Anyway, it's up to you.

Also, it wont be about free-choice unless your thumbnailer implements
the specification. Each new home-brew specification that isn't agreed by
multiple people adds API clutter to the platform.

ps. Specialized thumbnailers spec:

http://live.gnome.org/ThumbnailerSpec#head-83f1d6d2084e75742104681ad94c29b8d0dd2052

ps. Note that we might make minor changes to this spec in the following
days. Among them might be the optional Cancel() method and a parameter
to the Create() method called "scheduler" (which you can also ignore,
for now).


--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Philip Van Hoof
On Tue, 2009-10-20 at 13:08 +0200, Philip Van Hoof wrote:
> - You'll have to work with a queue handling the thumbnailing, as
> Create isn't allowed to block, which means that GThreadQueue could for
> example be used (which means that your work will involve dealing with
> threads).

Sorry that's GThreadPool, not queue. I have too many 'queue' words in my
head at the moment ;-)


--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Bugzilla from markg85@gmail.com
In reply to this post by Philip Van Hoof
On Tue, Oct 20, 2009 at 1:08 PM, Philip Van Hoof <[hidden email]> wrote:

> On Mon, 2009-10-19 at 21:35 +0200, Mark wrote:
>
>> For Jannis and Philip,
>> Nice tumbler talk but could you two make suggestions for my project? ^_^
>
> As I already wrote:
>
> A PDF thumbnailer that implements the 'specialized thumbnailer' spec
> that doesn't need to link with gdkpixbuf.
>
> I think that matches your project description, it fits in the architec-
> ture of Tumbler (and if done right we could make this a project that
> many people will use and install alongside Tumbler).
>
> It's much more simple than developing an entire thumbnailer, as you only
> need to implement one D-Bus method called "Create".
>
> - You'll have to work with a queue handling the thumbnailing, as Create
>  isn't allowed to block, which means that GThreadQueue could for
>  example be used (which means that your work will involve dealing with
>  threads).
>
> - You'll need to deal with DBus .service registration
>
> - You'll need to code against a specification (which is in general
>  harder than doing your own thing - but schools like that)
>
> - It's a thumbnailer service and it could work standalone (which means
>  that it fits your requirements for school)
>
> - You wont have the NIH syndrome. Nobody has yet made a PDF thumbnailer
>  that implements the 'specialized thumbnailer' spec
>
> - It sounds doable within 8 weeks
>
> I suggest that you set up a gitorious repository, start with making a
> skeleton out of the maemo-video-thumbnailer project, adapt all the files
> that you read about in the specification, hollow out the methods, and
> then implement them for PDF files instead of video (GStreamer).
>
> You can check out libpoppler for dealing with PDF files. Poppler can be
> compiled not to use gdkpixbuf, but instead cairo as far as I know.
>
> I strongly advise to do that.
>
>
> Anyway, it's up to you.
>
> Also, it wont be about free-choice unless your thumbnailer implements
> the specification. Each new home-brew specification that isn't agreed by
> multiple people adds API clutter to the platform.
>
> ps. Specialized thumbnailers spec:
>
> http://live.gnome.org/ThumbnailerSpec#head-83f1d6d2084e75742104681ad94c29b8d0dd2052
>
> ps. Note that we might make minor changes to this spec in the following
> days. Among them might be the optional Cancel() method and a parameter
> to the Create() method called "scheduler" (which you can also ignore,
> for now).
>
>
> --
> Philip Van Hoof, freelance software developer
> home: me at pvanhoof dot be
> gnome: pvanhoof at gnome dot org
> http://pvanhoof.be/blog
> http://codeminded.be
>
>

I do miss some vital parts:
- Designing the daemon and plugin architecture
- Making those 2

That's what i see missing now but i probably missed a few other parts.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Philip Van Hoof
On Tue, 2009-10-20 at 14:33 +0200, Mark wrote:
> On Tue, Oct 20, 2009 at 1:08 PM, Philip Van Hoof <[hidden email]> wrote:
> > On Mon, 2009-10-19 at 21:35 +0200, Mark wrote:

> >> For Jannis and Philip,
> >> Nice tumbler talk but could you two make suggestions for my project? ^_^

> > As I already wrote:
> >
> > A PDF thumbnailer that implements the 'specialized thumbnailer' spec
> > that doesn't need to link with gdkpixbuf.

[CUT]

Please reply inline and cut away non-relevant things.

> I do miss some vital parts:
> - Designing the daemon and plugin architecture
> - Making those 2
>
> That's what i see missing now but i probably missed a few other parts.


If you want to make a functional analysis of Tumbler, then go ahead. If
you want to draw cute UML diagrams with the classes and interfaces being
used, yeah sure. Sounds like useful documentation that doesn't exist atm

What does "Making those 2" mean? You still have to make the specialized
PDF thumbnailer. You can reuse the maemo-video-thumbnailer for getting a
quick skeleton of the code. But if you prefer making an all new one in
C++ or whatever ... yeah sure.

I think you are just looking for a reason to make your own one. That's
you decision of course. It's called NIH, but anyway (I can't and wont
stop you from doing that).


--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Bugzilla from markg85@gmail.com
>> I do miss some vital parts:
>> - Designing the daemon and plugin architecture
>> - Making those 2
>>
>> That's what i see missing now but i probably missed a few other parts.
>
>
> If you want to make a functional analysis of Tumbler, then go ahead. If
> you want to draw cute UML diagrams with the classes and interfaces being
> used, yeah sure. Sounds like useful documentation that doesn't exist atm
>
> What does "Making those 2" mean? You still have to make the specialized
> PDF thumbnailer. You can reuse the maemo-video-thumbnailer for getting a
> quick skeleton of the code. But if you prefer making an all new one in
> C++ or whatever ... yeah sure.
>
1. designing a daemon
2. designing a plugin architecture
3. making the daemon
4. making the plugin architecture
.... like that
> I think you are just looking for a reason to make your own one. That's
> you decision of course. It's called NIH, but anyway (I can't and wont
> stop you from doing that).

you just don't seem to get the point.
I need to build something from the ground up (making uml, class
diagrams and such).. and based on that i need to make the actual
program.
Tumbler is existing already! i would be making those diagrams based on
the current inner working which is not the way to go.

Oke, i know that for each project i start outside of school i don't
make a design at all or a very simple one and in that case i could
perfectly help tumbler.
That, sadly, isn't the case (which i told you already on irc)

Just for that reason alone tumbler isn't a fine project for me to join
in this case.
Also i would like to learn as much as possible and that is less likely
to happen if i join tumbler.

I am not looking for reasons to make it all myself.. the requirements
simple.. require that.

Now can we please quit bashing the idea that there will be 2
thumbnailing services in a few months time and can i get some
constructive feedback about the ideas in my first post?
Can i get the:
- Git
- gnome sub domain
- blog for this project on planet gnome and/or gtk

As said a few times. the outline is right there (in the first post)
now all i can do is steer some more in one direction or the other. I
personally would like to steer in the optimizing direction...
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Philip Van Hoof
On Tue, 2009-10-20 at 16:34 +0200, Mark wrote:
> >> I do miss some vital parts:
> >> - Designing the daemon and plugin architecture
> >> - Making those 2
> >>
> >> That's what i see missing now but i probably missed a few other parts.

> > What does "Making those 2" mean? [CUT]

> 1. designing a daemon

With a specialized thumbnailer for PDF thumbnails you'll be designing a
daemon.

> 2. designing a plugin architecture

I don't know what that means anyway. A plugin "architecture" can mean:

- Registering yourself to a DBus service, so that it knows about your
  existence and can delegate work to you. This is what a specialized
  thumbnailer is wrt Tumbler. You could see such a thumbnailer as a
  plugin for Tumbler (or any other thumbnail service).

- Implementing an interface in Java or .NET, or implementing Event
  handlers in .NET, or anonymous classes in Java, or delegates in C#,
  that provide functionality that a core application doesn't have and
  that you provide dynamically by installing an assembly (or .class
  file, in Java) somewhere "on demand".

- Making a struct with a bunch of function pointers that you return at a
  "get_plugin_info"-like function that you find with dlsym after you
  dlopen a .so file from a core application "on demand". You can also
  use GModule in GLib to make all this a lot more easy.

- etc ...

> 3. making the daemon

With a specialized thumbnailer for PDF thumbnails you'll be making a
daemon.

> 4. making the plugin architecture

Same answer as #2

> .... like that

.... Yes?

> > I think you are just looking for a reason to make your own one. That's
> > you decision of course. It's called NIH, but anyway (I can't and wont
> > stop you from doing that).
>
> you just don't seem to get the point.

I'm quite afraid that I do get the point ... :-\

> I need to build something from the ground up (making uml, class
> diagrams and such).. and based on that i need to make the actual
> program.

Yes, you could do that for a specialized thumbnailer for PDF thumbnails.

> Tumbler is existing already! i would be making those diagrams based on
> the current inner working which is not the way to go.

There's no specialized thumbnailer for PDF thumbnails (for Tumbler) yet.

> Oke, i know that for each project i start outside of school i don't
> make a design at all or a very simple one and in that case i could
> perfectly help tumbler.

You can help Tumbler by making a specialized thumbnailer that makes PDF
thumbnails, for example.

> That, sadly, isn't the case (which i told you already on irc)

Untrue, specialized thumbnailer that makes PDF thumbnails.

> Just for that reason alone tumbler isn't a fine project for me to join
> in this case.
> Also i would like to learn as much as possible and that is less likely
> to happen if i join tumbler.

Eh?

I disagree. But oh well.

> I am not looking for reasons to make it all myself.. the requirements
> simple.. require that.

Untrue, I know about your requirements. I read them. And a specialized
thumbnailer, that for example makes PDF thumbnails, fits it perfectly.

> Now can we please quit bashing the idea that there will be 2
> thumbnailing services in a few months time and can i get some
> constructive feedback about the ideas in my first post?

The replies of the people who have replied so far is the constructive
feedback on your first post.

> Can i get the:
> - Git
> - gnome sub domain
> - blog for this project on planet gnome and/or gtk

That's not up to me.

> As said a few times. the outline is right there (in the first post)
> now all i can do is steer some more in one direction or the other. I
> personally would like to steer in the optimizing direction...




--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

RE: Thumbnailing service project; opinions, suggestions?

sbaka
In reply to this post by Bugzilla from markg85@gmail.com
[ CUT ]

Sorry to keep chiming in, but regrading the statement:

> you just don't seem to get the point.
> I need to build something from the ground up (making uml, class
> diagrams and such).. and based on that i need to make the actual
> program.
> Tumbler is existing already! i would be making those diagrams based on
> the current inner working which is not the way to go.

[CUT]

I think everyone understands what you are doing, I think your the one missing the point; from what I gather, many on this very list, have given you some very good constructive advice on what to do, if you want to do this from the ground up. So be it. They are also very prudently advising you that this is not needed, and would ONLY serve as a class project, so:

> Can i get the:
> - Git
> - gnome sub domain
> - blog for this project on planet gnome and/or gtk

No one is bashing anything, but despite the many who agree, that this project is NOT a requirement for GNOME or GTK (and since it is only for school, a place that rots the brain) I would be shocked... SHOCKED... if they provided you with a GIT, a gnome sub domain, and a blog.

My friend, understanding is a two way street, and I'm not sure if any one on this list will convince you of any other path, than the one you are on. But don't expect them to hold your hand in this process as well.

You want to do this do it:
Put up your own GIT repo.
Use a domain name off of your own schools website.
and create your own blog for the project.

I doubt any of this will effect your grade. Frankly it simply sounds like your trying to get your name on the site, which will help with other prospects. I would LOVE to be attached to such a project, many would.

Open source is not about having many choices of software that do the same thing, it is about having many people working together in a cooperative (operative word here) to create something for the people, by the people, that will benefit the people, and in the process have some fun doing what we love. Open source is about freedom to do as you will, without the fear of big bro slamming you. Open source has never NEVER been about quantity, and has everything EVERYTHING to do with quality.

IMHO
shawn


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Cosimo Cecchi-2
In reply to this post by Bugzilla from markg85@gmail.com
Hi Mark,

On Tue, 2009-10-20 at 16:34 +0200, Mark wrote:

> Now can we please quit bashing the idea that there will be 2
> thumbnailing services in a few months time and can i get some
> constructive feedback about the ideas in my first post?
> Can i get the:
> - Git
> - gnome sub domain
> - blog for this project on planet gnome and/or gtk

gtk-devel-list is *really* not the right place for this kind of
requests. Please read [1] for information about the GIT account
requests, [2] for Planet GNOME and [3] for the GNOME website.
Anyway, it seems to me that not having these kind of resources available
right now (or even not having them at all) should not block any
development of your project.

For what concerns the project itself, I don't like see people
duplicating efforts; as others already told you, I really can't see the
point of rush-writing a daemon that will be, in your own words, less
functional than something which is already widely used in two big
platforms and which has a well-defined spec many people already agreed
upon. Unless you see something so fundamentally broken in the
ThumanailerSpec or in Tumbler that could only be solved with a rewrite
from scratch of everything.

If I were you, I would really make a step back and reconsider what other
people proposed you, be it a specialized thumbnailer for some format, or
a library with optimized thumbnailing algorithms with a demo test-drive
thumbnailer attached.

[1] http://live.gnome.org/NewAccounts
[2] http://live.gnome.org/PlanetGnome
[3] http://live.gnome.org/Sysadmin/WebSites

Regards,

Cosimo

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Bugzilla from markg85@gmail.com
>> Can i get the:
>> - Git
>> - gnome sub domain
>> - blog for this project on planet gnome and/or gtk
>
> No one is bashing anything, but despite the many who agree, that this
> project is NOT a requirement for GNOME or GTK (and since it is only for
> school, a place that rots the brain) I would be shocked... SHOCKED... if
> they provided you with a GIT, a gnome sub domain, and a blog.

Then you have the wrong impression or didn't read everything.
It was supposed to be just a single place where all information and
progress would be collected.
It was not at all my intend to somehow just get my name on there.

Don't get me wrong. I can provide myself with all those requests bit
not on the gnome site and i would have preferred that.

On Tue, Oct 20, 2009 at 6:11 PM, Cosimo Cecchi <[hidden email]> wrote:

> Hi Mark,
>
> On Tue, 2009-10-20 at 16:34 +0200, Mark wrote:
>
>> Now can we please quit bashing the idea that there will be 2
>> thumbnailing services in a few months time and can i get some
>> constructive feedback about the ideas in my first post?
>> Can i get the:
>> - Git
>> - gnome sub domain
>> - blog for this project on planet gnome and/or gtk
>
> gtk-devel-list is *really* not the right place for this kind of
> requests. Please read [1] for information about the GIT account
> requests, [2] for Planet GNOME and [3] for the GNOME website.
> Anyway, it seems to me that not having these kind of resources available
> right now (or even not having them at all) should not block any
> development of your project.
It's not blocking or holding the project.. but then it might just end
up on a local repository to never get released simply because i leave
it rot on my hdd.
It would just, for me, be nice that something that i make (also for
gnome) to be hosted on a oss project and gnome does seem to fit it.
>
> For what concerns the project itself, I don't like see people
> duplicating efforts; as others already told you, I really can't see the
> point of rush-writing a daemon that will be, in your own words, less
> functional than something which is already widely used in two big
> platforms and which has a well-defined spec many people already agreed
> upon. Unless you see something so fundamentally broken in the
> ThumanailerSpec or in Tumbler that could only be solved with a rewrite
> from scratch of everything.
I also hate to see myself duplicating something that is existing out
there but i learn a lot from it by doing so.
>
> If I were you, I would really make a step back and reconsider what other
> people proposed you, be it a specialized thumbnailer for some format, or
> a library with optimized thumbnailing algorithms with a demo test-drive
> thumbnailer attached.
If it wasn't a school project i would have done exactly that.
As said a few times. I can't take a step back. the projects outline is
set and must be made now.

And to all.
Don't get me wrong! I do still want to make this project and have been
doing thumbnail benchmarks for the last few months as a "startup" for
the project. I do have ideas on how to make it better, faster and
"cooler" and yes much of that is in tumbler (which i didn't know a few
months ago).

So, it seems this is going to be a project just for school with no
interesting parts for tumbler, glib or gnome in general. I would have
liked it seen different but learning a lot from this project is worth
a lot as well.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Andrew Cowie
In reply to this post by Bugzilla from markg85@gmail.com
Mark,

On Mon, 2009-10-19 at 16:32 +0200, Mark wrote:
> on school i study ...
> So this project, described in depth below...

Keep in mind that contribution to an open source project doesn't have to
be bounded by school projects or an institution's academic calendar; you
are welcome to continue participating in the evolution of GTK long into
the future; indeed, people are going to be happier to work with you if
they think that you're going to be around for a while, thereby making
their investment in helping you more likely to have a long term impact.

GTK is, of course, a very mature project (which in practise means it is
a core piece of the infrastructure of a huge number of production [in
use] systems), and it is worked on by people with a broad cross section
of interests and needs.

Which is why you've noticed considerable discussion from your original
message, and people adding other aspects to be considered, especially as
the specific thing you proposed intersects with ongoing FreeDesktop and
GNOME work. This may well take it out of the scope of something you can
do in your available school time, but that's the reality of something
that is as critical a player in the desktop as GTK. Regardless, I hope
you will choose to participate in the broader development of the
platform.

Finally, I would observe that proposing ideas is important (including
for helping find people who might mentor you), but the best way to show
the quality of your idea is to write code implementing it and then
submit a patch for consideration.

AfC
Sydney


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thumbnailing service project; opinions, suggestions?

Bugzilla from markg85@gmail.com
On Wed, Oct 21, 2009 at 1:39 AM, Andrew Cowie
<[hidden email]> wrote:

> Mark,
>
> On Mon, 2009-10-19 at 16:32 +0200, Mark wrote:
>> on school i study ...
>> So this project, described in depth below...
>
> Keep in mind that contribution to an open source project doesn't have to
> be bounded by school projects or an institution's academic calendar; you
> are welcome to continue participating in the evolution of GTK long into
> the future; indeed, people are going to be happier to work with you if
> they think that you're going to be around for a while, thereby making
> their investment in helping you more likely to have a long term impact.
I know. I did contribute patched to gnome and am around here for years
but just recently (as in the last few months) became capable of
"understanding" parts of glib and making patches for things that are
broken, have bugs or can be better (like:
https://bugzilla.gnome.org/show_bug.cgi?id=594918)
>
> GTK is, of course, a very mature project (which in practise means it is
> a core piece of the infrastructure of a huge number of production [in
> use] systems), and it is worked on by people with a broad cross section
> of interests and needs.
In the end my project might be a pixbuf alternative ^_- . i might have
added that blink but that thought did cross my mind more then once and
if i optimize it the way i want (with opencl and such) then it might
just get close to a new proposal to replace gdk-pixbuf with
"Aldebaran" (the name of the project:
http://en.wikipedia.org/wiki/Aldebaran .. i kinda like star names)
with it's repo here: http://gitorious.org/aldebaran
Other then that there is no GTK coding involved in it. only Glib.
>
> Which is why you've noticed considerable discussion from your original
> message, and people adding other aspects to be considered, especially as
> the specific thing you proposed intersects with ongoing FreeDesktop and
> GNOME work. This may well take it out of the scope of something you can
> do in your available school time, but that's the reality of something
> that is as critical a player in the desktop as GTK. Regardless, I hope
> you will choose to participate in the broader development of the
> platform.
This project will, if i not keep it tightly in bounds, go out of
scope. So, there will probably be a future for this project but
probably not as a thumbnailing service. In the end (and now i speak of
one year from now) this project will either be dead or will be a image
(scaling) library which Tumbler might even use ;). Note. this is all
just guessing. it might end completely different
>
> Finally, I would observe that proposing ideas is important (including
> for helping find people who might mentor you), but the best way to show
> the quality of your idea is to write code implementing it and then
> submit a patch for consideration.
That is conflicting with others (although not said here). I used to
hear things like: make a design, make a proposal, see how that works
and then, if it's considered interesting write code. And that is
exactly how this is going. What you propose is what would have me
preference.
>
> AfC
> Sydney

Andrew, thank you for your nice post. It did give me some thought of
how this project might have evolved in roughly a year from now.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list