From: Ryan R. <rya...@gm...> - 2009-05-18 09:31:11
|
Hello, I am trying to write an EThumb_Plugin to load an xml file with an embbeded jpeg file. However, the plugins written for Ethumb need "ethumb_private.h". This is not very practical to develop plugins outside of the source tree. Is there any thoughts on this? I will help if needed. thanks, ryan |
From: Gustavo S. B. <bar...@pr...> - 2009-05-18 10:46:53
|
On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <rya...@gm...> wrote: > Hello, > > I am trying to write an EThumb_Plugin to load an xml file with an > embbeded jpeg file. However, the plugins written for Ethumb need > "ethumb_private.h". This is not very practical to develop plugins > outside of the source tree. > > Is there any thoughts on this? I will help if needed. yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: the attributes we need could have setters in Ethumb.h or Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to access canvas and all, then move plugins to use it instead. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Rafael A. <ant...@pr...> - 2009-05-18 21:30:26
|
On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri <bar...@pr...> wrote: > On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <rya...@gm...> wrote: >> Hello, >> >> I am trying to write an EThumb_Plugin to load an xml file with an >> embbeded jpeg file. However, the plugins written for Ethumb need >> "ethumb_private.h". This is not very practical to develop plugins >> outside of the source tree. >> >> Is there any thoughts on this? I will help if needed. > > yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: > the attributes we need could have setters in Ethumb.h or > Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to > access canvas and all, then move plugins to use it instead. I've just added some getters to Ethumb API. I think they are enough (at least to my plugins), but let me know if you need any other. -- Rafael Antognolli |
From: Viktor K. <vko...@gm...> - 2009-05-18 22:13:48
|
On Mon, 2009-05-18 at 18:30 -0300, Rafael Antognolli wrote: > On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri > <bar...@pr...> wrote: > > On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <rya...@gm...> wrote: > >> Hello, > >> > >> I am trying to write an EThumb_Plugin to load an xml file with an > >> embbeded jpeg file. However, the plugins written for Ethumb need > >> "ethumb_private.h". This is not very practical to develop plugins > >> outside of the source tree. > >> > >> Is there any thoughts on this? I will help if needed. > > > > yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: > > the attributes we need could have setters in Ethumb.h or > > Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to > > access canvas and all, then move plugins to use it instead. > > I've just added some getters to Ethumb API. I think they are enough > (at least to my plugins), but let me know if you need any other. maybe this is the right thread to brings this up: could be a good idea to have a some sort of generic getter/setter that sets properties for plugins to look at. Instead of having ethumb_video_time_get|set, and the document page equivalent, it would be better to have ethumb_property_get|set or something of that sort, so that plugins can be able to obtain other properties that could be useful, without adding more setters and getters. This would also make the video_time and document_page functions obsolete. > |
From: Rafael A. <ant...@pr...> - 2009-05-19 11:35:44
|
On Mon, May 18, 2009 at 7:13 PM, Viktor Kojouharov <vko...@gm...> wrote: > On Mon, 2009-05-18 at 18:30 -0300, Rafael Antognolli wrote: >> On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri >> <bar...@pr...> wrote: >> > On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <rya...@gm...> wrote: >> >> Hello, >> >> >> >> I am trying to write an EThumb_Plugin to load an xml file with an >> >> embbeded jpeg file. However, the plugins written for Ethumb need >> >> "ethumb_private.h". This is not very practical to develop plugins >> >> outside of the source tree. >> >> >> >> Is there any thoughts on this? I will help if needed. >> > >> > yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: >> > the attributes we need could have setters in Ethumb.h or >> > Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to >> > access canvas and all, then move plugins to use it instead. >> >> I've just added some getters to Ethumb API. I think they are enough >> (at least to my plugins), but let me know if you need any other. > > > maybe this is the right thread to brings this up: > > could be a good idea to have a some sort of generic getter/setter that > sets properties for plugins to look at. Instead of having > ethumb_video_time_get|set, and the document page equivalent, it would be > better to have ethumb_property_get|set or something of that sort, so > that plugins can be able to obtain other properties that could be > useful, without adding more setters and getters. This would also make > the video_time and document_page functions obsolete. I agree. I only have made these video_time and document_page functions because it was simpler than having a generic property get/set function, and since I was not planning to write newer plugins soon, it wasn't really necessary. But maybe it's time to do it now. I'll take a look at it soon, just finishing the client/server stuff and some changes on ethumb lib itself. -- Rafael Antognolli |
From: Gustavo S. B. <bar...@pr...> - 2009-05-20 13:15:37
|
On Tue, May 19, 2009 at 1:35 PM, Rafael Antognolli <ant...@pr...> wrote: > On Mon, May 18, 2009 at 7:13 PM, Viktor Kojouharov > <vko...@gm...> wrote: >> On Mon, 2009-05-18 at 18:30 -0300, Rafael Antognolli wrote: >>> On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri >>> <bar...@pr...> wrote: >>> > On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <rya...@gm...> wrote: >>> >> Hello, >>> >> >>> >> I am trying to write an EThumb_Plugin to load an xml file with an >>> >> embbeded jpeg file. However, the plugins written for Ethumb need >>> >> "ethumb_private.h". This is not very practical to develop plugins >>> >> outside of the source tree. >>> >> >>> >> Is there any thoughts on this? I will help if needed. >>> > >>> > yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: >>> > the attributes we need could have setters in Ethumb.h or >>> > Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to >>> > access canvas and all, then move plugins to use it instead. >>> >>> I've just added some getters to Ethumb API. I think they are enough >>> (at least to my plugins), but let me know if you need any other. >> >> >> maybe this is the right thread to brings this up: >> >> could be a good idea to have a some sort of generic getter/setter that >> sets properties for plugins to look at. Instead of having >> ethumb_video_time_get|set, and the document page equivalent, it would be >> better to have ethumb_property_get|set or something of that sort, so >> that plugins can be able to obtain other properties that could be >> useful, without adding more setters and getters. This would also make >> the video_time and document_page functions obsolete. > > I agree. I only have made these video_time and document_page functions > because it was simpler than having a generic property get/set > function, and since I was not planning to write newer plugins soon, it > wasn't really necessary. > > But maybe it's time to do it now. I'll take a look at it soon, just > finishing the client/server stuff and some changes on ethumb lib > itself. I disagree as this would defeat the purpose of plugins implementing a set of features. For example, if you start to make it open, applications would need to know deep into plugins, and that's not good. By forcing a explicit api we can stop and think about stuff, how to unify and be consistent. Otherwise applications will start to use emotion plugin on frames and xine plugin on time and mplayer plugins on tick based, defeating the purpose of the whole thing. So far we did document/paging and video, if you need new kind of feature, just say, let's think about it and design a good system, it might help existing stuff as well. As for "generic" property, it would be as hard as the current implementation, instead of giving a single parameter and changing the value in structure, just give two and append to a list. But please don't do it, it will harm more than help the project. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Viktor K. <vko...@gm...> - 2009-05-20 14:10:39
|
On Wed, 2009-05-20 at 15:15 +0200, Gustavo Sverzut Barbieri wrote: > On Tue, May 19, 2009 at 1:35 PM, Rafael Antognolli > <ant...@pr...> wrote: > > On Mon, May 18, 2009 at 7:13 PM, Viktor Kojouharov > > <vko...@gm...> wrote: > >> On Mon, 2009-05-18 at 18:30 -0300, Rafael Antognolli wrote: > >>> On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri > >>> <bar...@pr...> wrote: > >>> > On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <rya...@gm...> wrote: > >>> >> Hello, > >>> >> > >>> >> I am trying to write an EThumb_Plugin to load an xml file with an > >>> >> embbeded jpeg file. However, the plugins written for Ethumb need > >>> >> "ethumb_private.h". This is not very practical to develop plugins > >>> >> outside of the source tree. > >>> >> > >>> >> Is there any thoughts on this? I will help if needed. > >>> > > >>> > yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: > >>> > the attributes we need could have setters in Ethumb.h or > >>> > Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to > >>> > access canvas and all, then move plugins to use it instead. > >>> > >>> I've just added some getters to Ethumb API. I think they are enough > >>> (at least to my plugins), but let me know if you need any other. > >> > >> > >> maybe this is the right thread to brings this up: > >> > >> could be a good idea to have a some sort of generic getter/setter that > >> sets properties for plugins to look at. Instead of having > >> ethumb_video_time_get|set, and the document page equivalent, it would be > >> better to have ethumb_property_get|set or something of that sort, so > >> that plugins can be able to obtain other properties that could be > >> useful, without adding more setters and getters. This would also make > >> the video_time and document_page functions obsolete. > > > > I agree. I only have made these video_time and document_page functions > > because it was simpler than having a generic property get/set > > function, and since I was not planning to write newer plugins soon, it > > wasn't really necessary. > > > > But maybe it's time to do it now. I'll take a look at it soon, just > > finishing the client/server stuff and some changes on ethumb lib > > itself. > > I disagree as this would defeat the purpose of plugins implementing a > set of features. For example, if you start to make it open, > applications would need to know deep into plugins, and that's not > good. By forcing a explicit api we can stop and think about stuff, how > to unify and be consistent. Otherwise applications will start to use > emotion plugin on frames and xine plugin on time and mplayer plugins > on tick based, defeating the purpose of the whole thing. So far we did > document/paging and video, if you need new kind of feature, just say, > let's think about it and design a good system, it might help existing > stuff as well. I disagree with this. Its entirely up to the plugin to decide what features it can support. Just because the current API covers two cases, doesn't mean that you're safe. I can think of a few other properties besides frame or document page for plugins, and I'm sure other people might think of others as well. There should be no reason to limit what plugins support by hard-coding what properties any potential plugins should have. And if they are properly documented and there's even slight coordination, I doubt that the scenario you showed would surface. > > As for "generic" property, it would be as hard as the current > implementation, instead of giving a single parameter and changing the > value in structure, just give two and append to a list. But please > don't do it, it will harm more than help the project. you can also use variable arguments to add as many properties in one go as you need. > |
From: Gustavo S. B. <bar...@pr...> - 2009-05-20 16:52:55
|
2009/5/20 Viktor Kojouharov <vko...@gm...>: > On Wed, 2009-05-20 at 15:15 +0200, Gustavo Sverzut Barbieri wrote: >> On Tue, May 19, 2009 at 1:35 PM, Rafael Antognolli >> <ant...@pr...> wrote: >> > On Mon, May 18, 2009 at 7:13 PM, Viktor Kojouharov >> > <vko...@gm...> wrote: >> >> On Mon, 2009-05-18 at 18:30 -0300, Rafael Antognolli wrote: >> >>> On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri >> >>> <bar...@pr...> wrote: >> >>> > On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <rya...@gm...> wrote: >> >>> >> Hello, >> >>> >> >> >>> >> I am trying to write an EThumb_Plugin to load an xml file with an >> >>> >> embbeded jpeg file. However, the plugins written for Ethumb need >> >>> >> "ethumb_private.h". This is not very practical to develop plugins >> >>> >> outside of the source tree. >> >>> >> >> >>> >> Is there any thoughts on this? I will help if needed. >> >>> > >> >>> > yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: >> >>> > the attributes we need could have setters in Ethumb.h or >> >>> > Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to >> >>> > access canvas and all, then move plugins to use it instead. >> >>> >> >>> I've just added some getters to Ethumb API. I think they are enough >> >>> (at least to my plugins), but let me know if you need any other. >> >> >> >> >> >> maybe this is the right thread to brings this up: >> >> >> >> could be a good idea to have a some sort of generic getter/setter that >> >> sets properties for plugins to look at. Instead of having >> >> ethumb_video_time_get|set, and the document page equivalent, it would be >> >> better to have ethumb_property_get|set or something of that sort, so >> >> that plugins can be able to obtain other properties that could be >> >> useful, without adding more setters and getters. This would also make >> >> the video_time and document_page functions obsolete. >> > >> > I agree. I only have made these video_time and document_page functions >> > because it was simpler than having a generic property get/set >> > function, and since I was not planning to write newer plugins soon, it >> > wasn't really necessary. >> > >> > But maybe it's time to do it now. I'll take a look at it soon, just >> > finishing the client/server stuff and some changes on ethumb lib >> > itself. >> >> I disagree as this would defeat the purpose of plugins implementing a >> set of features. For example, if you start to make it open, >> applications would need to know deep into plugins, and that's not >> good. By forcing a explicit api we can stop and think about stuff, how >> to unify and be consistent. Otherwise applications will start to use >> emotion plugin on frames and xine plugin on time and mplayer plugins >> on tick based, defeating the purpose of the whole thing. So far we did >> document/paging and video, if you need new kind of feature, just say, >> let's think about it and design a good system, it might help existing >> stuff as well. > I disagree with this. Its entirely up to the plugin to decide what > features it can support. Just because the current API covers two cases, > doesn't mean that you're safe. I can think of a few other properties > besides frame or document page for plugins, and I'm sure other people > might think of others as well. As you can imagine I disagree with that. First, the idea with plugins was to transparently handle media, not to specifically talk to one. Applications talk to thumbnailer and say "get me a visual representation of this file", and you specify some properties you'd like. Actually these properties should be guessed, but it's too difficult to guess right so we're giving hints. For example, if it was easy to avoid black screens and producer's logo/introduction from videos without wasting too much cpu time, we'd not even specify video properties. Same for documents, if we can find a good heuristics to avoid cover/empty/index pages, we could avoid these properties at all. Remember we're doing a thumbnailer, not a general purpose image resizing framework, the main goal is to make it easy to generate visual representation of files, not to replace gimp/imagemagick. And as I said, these properties are hints, of course plugins might not implement it. But when plugins implement, they have a rule of what to implement. Example, we know video have couple of properties with well known meaning. Generally we should not even specify such properties, but if we do (to overcome technical problems), we might present user with an interface to set such programs, even visually as Playstation3 do for video, you know the parameters you need to set. If we start to let it too loose we'll have to force apps to query installer plugins, then their properties and then try to map these to ui. Xine and others tried to do such a generic property-ui mapper and it sucks hard. > There should be no reason to limit what > plugins support by hard-coding what properties any potential plugins > should have. I really believe it's not a limitation, it's just forcing us to think, design and implement in central place. It will avoid fragmentation and help system overall. We tried to design it to fit cases we imagined, but if you really think of extra parameters, write them in a wiki and let us know, let's discuss and they'll go into the public api. This helps everybody. > And if they are properly documented and there's even slight > coordination, I doubt that the scenario you showed would surface. This is the same as saying "plugins will write to a memory address that is docummented" (same process usage, regular ethumb api), or "plugins will register a dbus interface on their own to handle specific properties" (client-server api). Think about these, they're really ugly solutions, aren't they? But that's exactly what you're asking for, but dressed in the form of a api method. >> As for "generic" property, it would be as hard as the current >> implementation, instead of giving a single parameter and changing the >> value in structure, just give two and append to a list. But please >> don't do it, it will harm more than help the project. > you can also use variable arguments to add as many properties in one go > as you need. that's syntax sugar, it's easy. I'm more concerned with the system usefulness of such thing. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Gustavo S. B. <bar...@pr...> - 2009-05-20 22:08:43
|
2009/5/20 Jose Gonzalez <jos...@ju...>: > Gustavo wrote: > >> 2009/5/20 Viktor Kojouharov <vko...@gm...>: >> >>> >>> On Wed, 2009-05-20 at 15:15 +0200, Gustavo Sverzut Barbieri wrote: >>> >>>> >>>> On Tue, May 19, 2009 at 1:35 PM, Rafael Antognolli >>>> <ant...@pr...> wrote: >>>> >>>>> >>>>> On Mon, May 18, 2009 at 7:13 PM, Viktor Kojouharov >>>>> <vko...@gm...> wrote: >>>>> >>>>>> >>>>>> On Mon, 2009-05-18 at 18:30 -0300, Rafael Antognolli wrote: >>>>>> >>>>>>> >>>>>>> On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri >>>>>>> <bar...@pr...> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <rya...@gm...> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I am trying to write an EThumb_Plugin to load an xml file with an >>>>>>>>> embbeded jpeg file. However, the plugins written for Ethumb need >>>>>>>>> "ethumb_private.h". This is not very practical to develop plugins >>>>>>>>> outside of the source tree. >>>>>>>>> >>>>>>>>> Is there any thoughts on this? I will help if needed. >>>>>>>>> >>>>>>>> >>>>>>>> yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: >>>>>>>> the attributes we need could have setters in Ethumb.h or >>>>>>>> Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to >>>>>>>> access canvas and all, then move plugins to use it instead. >>>>>>>> >>>>>>> >>>>>>> I've just added some getters to Ethumb API. I think they are enough >>>>>>> (at least to my plugins), but let me know if you need any other. >>>>>>> >>>>>> >>>>>> maybe this is the right thread to brings this up: >>>>>> >>>>>> could be a good idea to have a some sort of generic getter/setter that >>>>>> sets properties for plugins to look at. Instead of having >>>>>> ethumb_video_time_get|set, and the document page equivalent, it would be >>>>>> better to have ethumb_property_get|set or something of that sort, so >>>>>> that plugins can be able to obtain other properties that could be >>>>>> useful, without adding more setters and getters. This would also make >>>>>> the video_time and document_page functions obsolete. >>>>>> >>>>> >>>>> I agree. I only have made these video_time and document_page functions >>>>> because it was simpler than having a generic property get/set >>>>> function, and since I was not planning to write newer plugins soon, it >>>>> wasn't really necessary. >>>>> >>>>> But maybe it's time to do it now. I'll take a look at it soon, just >>>>> finishing the client/server stuff and some changes on ethumb lib >>>>> itself. >>>>> >>>> >>>> I disagree as this would defeat the purpose of plugins implementing a >>>> set of features. For example, if you start to make it open, >>>> applications would need to know deep into plugins, and that's not >>>> good. By forcing a explicit api we can stop and think about stuff, how >>>> to unify and be consistent. Otherwise applications will start to use >>>> emotion plugin on frames and xine plugin on time and mplayer plugins >>>> on tick based, defeating the purpose of the whole thing. So far we did >>>> document/paging and video, if you need new kind of feature, just say, >>>> let's think about it and design a good system, it might help existing >>>> stuff as well. >>>> >>> >>> I disagree with this. Its entirely up to the plugin to decide what >>> features it can support. Just because the current API covers two cases, >>> doesn't mean that you're safe. I can think of a few other properties >>> besides frame or document page for plugins, and I'm sure other people >>> might think of others as well. >>> >> >> As you can imagine I disagree with that. First, the idea with plugins >> was to transparently handle media, not to specifically talk to one. >> Applications talk to thumbnailer and say "get me a visual >> representation of this file", and you specify some properties you'd >> like. Actually these properties should be guessed, but it's too >> difficult to guess right so we're giving hints. For example, if it was >> easy to avoid black screens and producer's logo/introduction from >> videos without wasting too much cpu time, we'd not even specify video >> properties. Same for documents, if we can find a good heuristics to >> avoid cover/empty/index pages, we could avoid these properties at all. >> Remember we're doing a thumbnailer, not a general purpose image >> resizing framework, the main goal is to make it easy to generate >> visual representation of files, not to replace gimp/imagemagick. >> >> And as I said, these properties are hints, of course plugins might not >> implement it. But when plugins implement, they have a rule of what to >> implement. Example, we know video have couple of properties with well >> known meaning. Generally we should not even specify such properties, >> but if we do (to overcome technical problems), we might present user >> with an interface to set such programs, even visually as Playstation3 >> do for video, you know the parameters you need to set. If we start to >> let it too loose we'll have to force apps to query installer plugins, >> then their properties and then try to map these to ui. Xine and others >> tried to do such a generic property-ui mapper and it sucks hard. >> >> >> >> >>> >>> There should be no reason to limit what >>> plugins support by hard-coding what properties any potential plugins >>> should have. >>> >> >> I really believe it's not a limitation, it's just forcing us to think, >> design and implement in central place. It will avoid fragmentation and >> help system overall. We tried to design it to fit cases we imagined, >> but if you really think of extra parameters, write them in a wiki and >> let us know, let's discuss and they'll go into the public api. This >> helps everybody. >> >> >> >>> >>> And if they are properly documented and there's even slight >>> coordination, I doubt that the scenario you showed would surface. >>> >> >> This is the same as saying "plugins will write to a memory address >> that is docummented" (same process usage, regular ethumb api), or >> "plugins will register a dbus interface on their own to handle >> specific properties" (client-server api). Think about these, they're >> really ugly solutions, aren't they? But that's exactly what you're >> asking for, but dressed in the form of a api method. >> >> >> >>>> >>>> As for "generic" property, it would be as hard as the current >>>> implementation, instead of giving a single parameter and changing the >>>> value in structure, just give two and append to a list. But please >>>> don't do it, it will harm more than help the project. >>>> >>> >>> you can also use variable arguments to add as many properties in one go >>> as you need. >>> >> >> that's syntax sugar, it's easy. I'm more concerned with the system >> usefulness of such thing. >> >> > > Well I like their idea and think they should give it a shot > and see what they can come up with. You're being overly picky > here in the name of some abstarct notion of 'quality control' > and what it's really amounting to is restriction and limitation. > The notion of having these plugins somehow being able to > use each other isn't all that big an impact here since most of > these would be one-time shots, not 30-times-per-sec deals.. and > you and raster actually wanted such a filters-pipeline in evas, > so it's odd you're against a similar capability here. > But even if these plugins don't evolve into such a system, > what they're proposing as a generic 'property/value' api for > controlling pluging states is very useful for having generic/ > loadable plugins.. rather than being restricted to some fixed > set of them with built-in special-purpose state api functions > for just this or that known or built-in plugin. > > There's a lot that can be done.. but not if arbitrary restrictins > are kept in the name of some fixed functionality that you happen > to want right now or some ideal notion that you can pick the > best centralized design that will cover all that's interesting. > > I'd say let Viktor and Rafael use their imagination and skills > and let them try and experiment and do their thing here. :) As I said we have a purpose for doing such Ethumb and we need to remember about it. We're not restricting one's capabilities in doing whatever he wants, evas is always there, everyone is free to write whatever stuff wanted, but in order to keep things manageable we need to balance features and restrictions and I think this is a good trade off. I'm still waiting to see concrete ideas of more ideas that can benefit most and not single special case. Really, there is always a balance of feature/configurability and ease of use. Evas is one example of such balance that I believe is good: it does not allow you to do everything, but the things that it allows you to do it does fast and it's very easy. If one want to do vector or direct pixel manipulation it's not the way to go, but if you want to do simple raster effects it's very powerful and easy. Gtk's TreeView/TreeStore is what I'd say is a bad balance, it allows you to do whatever you want, but it's very tricky to get right and the simplest table needs lots of work. I want to avoid having a thumbnail that can generate everything in every way but it's unmaintainable and awkward to use. And as I said, if you really want to experiment, try a global, mmap, file or export a dbus object to do that. It's as problematic, ugly but unleashes the power you want. If it proves to be good, we can absorb the idea in the main api. But I'm against fragmenting the application-thumbnailer relationship at this point. What we need are requirements, think about then and act. What we do not need is lots of special parameters growing out of nowhere and causing more headaches. Just imagine we add a generic name-value association, to do dbus we need to add way to serialize it, then to do configuration we need to add labels, descriptions, range and possible example usage, and at the end we have a complete mess that nobody can use properly :-( > PS. As a related aside here: I've actually been thinking of > making a small lib of smart-object based 'filters' for evas > using Jorge's new enesim capabilities.. ie. encapsulate some > filters/effects like blur, rounded-corners, bump-mapping, > displacement-mapping, faded-reflections, etc... via suitable > smart-class derived types with enesim as the implementation > source. That's wonderful! But do not forget about smart negotiation of buffers, so we can avoid copies, use hardware memory and all :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Jose G. <jos...@ju...> - 2009-05-21 00:48:13
|
>> PS. As a related aside here: I've actually been thinking of >> making a small lib of smart-object based 'filters' for evas >> using Jorge's new enesim capabilities.. ie. encapsulate some >> filters/effects like blur, rounded-corners, bump-mapping, >> displacement-mapping, faded-reflections, etc... via suitable >> smart-class derived types with enesim as the implementation >> source. >> > > That's wonderful! But do not forget about smart negotiation of > buffers, so we can avoid copies, use hardware memory and all :-) > It's up to each 'filter' to define its buffer size as suits its state. Any pipe-lining or other complex setups are up to users. The point is to implement useful filters/effects via a user-level mechanism with software routines, not provide an abstract interface that would be implemented internal to evas. If you want to have something built-in to evas, and you and raster have expressed that desire before, then dive in... :) ____________________________________________________________ Digital Photography - Click Now. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTDvmRalBeCxtLoDxrU3yrhWL4yoapXX4cGoIpUDXX1QqwYPMnfkLO/ |
From: Jose G. <jos...@ju...> - 2009-05-21 00:39:19
|
Gustavo Sverzut Barbieri wrote: > 2009/5/20 Jose Gonzalez <jos...@ju...>: > >> Gustavo wrote: >> >> >>> 2009/5/20 Viktor Kojouharov <vko...@gm...>: >>> >>> >>>> On Wed, 2009-05-20 at 15:15 +0200, Gustavo Sverzut Barbieri wrote: >>>> >>>> >>>>> On Tue, May 19, 2009 at 1:35 PM, Rafael Antognolli >>>>> <ant...@pr...> wrote: >>>>> >>>>> >>>>>> On Mon, May 18, 2009 at 7:13 PM, Viktor Kojouharov >>>>>> <vko...@gm...> wrote: >>>>>> >>>>>> >>>>>>> On Mon, 2009-05-18 at 18:30 -0300, Rafael Antognolli wrote: >>>>>>> >>>>>>> >>>>>>>> On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri >>>>>>>> <bar...@pr...> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <rya...@gm...> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I am trying to write an EThumb_Plugin to load an xml file with an >>>>>>>>>> embbeded jpeg file. However, the plugins written for Ethumb need >>>>>>>>>> "ethumb_private.h". This is not very practical to develop plugins >>>>>>>>>> outside of the source tree. >>>>>>>>>> >>>>>>>>>> Is there any thoughts on this? I will help if needed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: >>>>>>>>> the attributes we need could have setters in Ethumb.h or >>>>>>>>> Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to >>>>>>>>> access canvas and all, then move plugins to use it instead. >>>>>>>>> >>>>>>>>> >>>>>>>> I've just added some getters to Ethumb API. I think they are enough >>>>>>>> (at least to my plugins), but let me know if you need any other. >>>>>>>> >>>>>>>> >>>>>>> maybe this is the right thread to brings this up: >>>>>>> >>>>>>> could be a good idea to have a some sort of generic getter/setter that >>>>>>> sets properties for plugins to look at. Instead of having >>>>>>> ethumb_video_time_get|set, and the document page equivalent, it would be >>>>>>> better to have ethumb_property_get|set or something of that sort, so >>>>>>> that plugins can be able to obtain other properties that could be >>>>>>> useful, without adding more setters and getters. This would also make >>>>>>> the video_time and document_page functions obsolete. >>>>>>> >>>>>>> >>>>>> I agree. I only have made these video_time and document_page functions >>>>>> because it was simpler than having a generic property get/set >>>>>> function, and since I was not planning to write newer plugins soon, it >>>>>> wasn't really necessary. >>>>>> >>>>>> But maybe it's time to do it now. I'll take a look at it soon, just >>>>>> finishing the client/server stuff and some changes on ethumb lib >>>>>> itself. >>>>>> >>>>>> >>>>> I disagree as this would defeat the purpose of plugins implementing a >>>>> set of features. For example, if you start to make it open, >>>>> applications would need to know deep into plugins, and that's not >>>>> good. By forcing a explicit api we can stop and think about stuff, how >>>>> to unify and be consistent. Otherwise applications will start to use >>>>> emotion plugin on frames and xine plugin on time and mplayer plugins >>>>> on tick based, defeating the purpose of the whole thing. So far we did >>>>> document/paging and video, if you need new kind of feature, just say, >>>>> let's think about it and design a good system, it might help existing >>>>> stuff as well. >>>>> >>>>> >>>> I disagree with this. Its entirely up to the plugin to decide what >>>> features it can support. Just because the current API covers two cases, >>>> doesn't mean that you're safe. I can think of a few other properties >>>> besides frame or document page for plugins, and I'm sure other people >>>> might think of others as well. >>>> >>>> >>> As you can imagine I disagree with that. First, the idea with plugins >>> was to transparently handle media, not to specifically talk to one. >>> Applications talk to thumbnailer and say "get me a visual >>> representation of this file", and you specify some properties you'd >>> like. Actually these properties should be guessed, but it's too >>> difficult to guess right so we're giving hints. For example, if it was >>> easy to avoid black screens and producer's logo/introduction from >>> videos without wasting too much cpu time, we'd not even specify video >>> properties. Same for documents, if we can find a good heuristics to >>> avoid cover/empty/index pages, we could avoid these properties at all. >>> Remember we're doing a thumbnailer, not a general purpose image >>> resizing framework, the main goal is to make it easy to generate >>> visual representation of files, not to replace gimp/imagemagick. >>> >>> And as I said, these properties are hints, of course plugins might not >>> implement it. But when plugins implement, they have a rule of what to >>> implement. Example, we know video have couple of properties with well >>> known meaning. Generally we should not even specify such properties, >>> but if we do (to overcome technical problems), we might present user >>> with an interface to set such programs, even visually as Playstation3 >>> do for video, you know the parameters you need to set. If we start to >>> let it too loose we'll have to force apps to query installer plugins, >>> then their properties and then try to map these to ui. Xine and others >>> tried to do such a generic property-ui mapper and it sucks hard. >>> >>> >>> >>> >>> >>>> There should be no reason to limit what >>>> plugins support by hard-coding what properties any potential plugins >>>> should have. >>>> >>>> >>> I really believe it's not a limitation, it's just forcing us to think, >>> design and implement in central place. It will avoid fragmentation and >>> help system overall. We tried to design it to fit cases we imagined, >>> but if you really think of extra parameters, write them in a wiki and >>> let us know, let's discuss and they'll go into the public api. This >>> helps everybody. >>> >>> >>> >>> >>>> And if they are properly documented and there's even slight >>>> coordination, I doubt that the scenario you showed would surface. >>>> >>>> >>> This is the same as saying "plugins will write to a memory address >>> that is docummented" (same process usage, regular ethumb api), or >>> "plugins will register a dbus interface on their own to handle >>> specific properties" (client-server api). Think about these, they're >>> really ugly solutions, aren't they? But that's exactly what you're >>> asking for, but dressed in the form of a api method. >>> >>> >>> >>> >>>>> As for "generic" property, it would be as hard as the current >>>>> implementation, instead of giving a single parameter and changing the >>>>> value in structure, just give two and append to a list. But please >>>>> don't do it, it will harm more than help the project. >>>>> >>>>> >>>> you can also use variable arguments to add as many properties in one go >>>> as you need. >>>> >>>> >>> that's syntax sugar, it's easy. I'm more concerned with the system >>> usefulness of such thing. >>> >>> >>> >> Well I like their idea and think they should give it a shot >> and see what they can come up with. You're being overly picky >> here in the name of some abstarct notion of 'quality control' >> and what it's really amounting to is restriction and limitation. >> The notion of having these plugins somehow being able to >> use each other isn't all that big an impact here since most of >> these would be one-time shots, not 30-times-per-sec deals.. and >> you and raster actually wanted such a filters-pipeline in evas, >> so it's odd you're against a similar capability here. >> But even if these plugins don't evolve into such a system, >> what they're proposing as a generic 'property/value' api for >> controlling pluging states is very useful for having generic/ >> loadable plugins.. rather than being restricted to some fixed >> set of them with built-in special-purpose state api functions >> for just this or that known or built-in plugin. >> >> There's a lot that can be done.. but not if arbitrary restrictins >> are kept in the name of some fixed functionality that you happen >> to want right now or some ideal notion that you can pick the >> best centralized design that will cover all that's interesting. >> >> I'd say let Viktor and Rafael use their imagination and skills >> and let them try and experiment and do their thing here. :) >> > > As I said we have a purpose for doing such Ethumb and we need to > remember about it. We're not restricting one's capabilities in doing > whatever he wants, evas is always there, everyone is free to write > whatever stuff wanted, but in order to keep things manageable we need > to balance features and restrictions and I think this is a good trade > off. > > Evas is evas, this is its own lib for generating "thumbs". Some of that can have built-in cases that are important, but there's no a priori need to limit things to that. As to balancing features vs. restrictions.. Sure, that's always a given. But just why are your restrictions here soooo necessary that all is lost with a more flexible plugin system? You even mentioned something about it 'harming the project', tell me exactly HOW that would 'harm' anything? > I'm still waiting to see concrete ideas of more ideas that can benefit > most and not single special case. Really, there is always a balance of > feature/configurability and ease of use. Evas is one example of such > balance that I believe is good: it does not allow you to do > everything, but the things that it allows you to do it does fast and > it's very easy. If one want to do vector or direct pixel manipulation > it's not the way to go, but if you want to do simple raster effects > it's very powerful and easy. Gtk's TreeView/TreeStore is what I'd > Nonsense. It's just as possible to do vector stuff as raster stuff with evas, api wise. It's just a pain to support all the various engines people have been adding (in particular the 16bpp ones which you pushed for and now have no interest in supporting), and also to work with its primitive internal engine func api which was designed a long time ago for a quick and limited set of abilities. This latter wouldn't be such a big deal to change if again there were fewer engines. There's no loss and large gains in having evas support vgfx directly, as well as further filter and other gfx notions. It's not a problem at all. There is a bit of other stuff at the canvas level that needs redoing if one wants to support complex gfx operations on arbitrary objects, and some of the problems there are due to the way smart-objects were implemented at the canvas level. But again, there's nothing that can't be done, and done quite efficiently - far more so than most current gfx libs do. > say is a bad balance, it allows you to do whatever you want, but it's > very tricky to get right and the simplest table needs lots of work. I > want to avoid having a thumbnail that can generate everything in every > way but it's unmaintainable and awkward to use. > > And as I said, if you really want to experiment, try a global, mmap, > file or export a dbus object to do that. It's as problematic, ugly but > unleashes the power you want. If it proves to be good, we can absorb > the idea in the main api. But I'm against fragmenting the > application-thumbnailer relationship at this point. What we need are > requirements, think about then and act. What we do not need is lots of > special parameters growing out of nowhere and causing more headaches. > Just imagine we add a generic name-value association, to do dbus we > need to add way to serialize it, then to do configuration we need to > add labels, descriptions, range and possible example usage, and at the > end we have a complete me > I'll leave it up to you and the others to come up with a good design here... Can you do it? :) ____________________________________________________________ Start Email Marketing - fast, affordable, and measurable. Click here. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEFeNwYieh0dm5yIlIoVU1P14sCnGtRLBvyk9ShjNxqc6ZIsMvwEA/ |
From: Gustavo S. B. <bar...@pr...> - 2009-05-22 16:15:09
|
2009/5/21 Jose Gonzalez <jos...@ju...>: > Gustavo Sverzut Barbieri wrote: >> >> 2009/5/20 Jose Gonzalez <jos...@ju...>: >> >>> >>> Gustavo wrote: >>> >>> >>>> >>>> 2009/5/20 Viktor Kojouharov <vko...@gm...>: >>>> >>>> >>>>> >>>>> On Wed, 2009-05-20 at 15:15 +0200, Gustavo Sverzut Barbieri wrote: >>>>> >>>>> >>>>>> >>>>>> On Tue, May 19, 2009 at 1:35 PM, Rafael Antognolli >>>>>> <ant...@pr...> wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> On Mon, May 18, 2009 at 7:13 PM, Viktor Kojouharov >>>>>>> <vko...@gm...> wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Mon, 2009-05-18 at 18:30 -0300, Rafael Antognolli wrote: >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri >>>>>>>>> <bar...@pr...> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <rya...@gm...> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I am trying to write an EThumb_Plugin to load an xml file with an >>>>>>>>>>> embbeded jpeg file. However, the plugins written for Ethumb need >>>>>>>>>>> "ethumb_private.h". This is not very practical to develop plugins >>>>>>>>>>> outside of the source tree. >>>>>>>>>>> >>>>>>>>>>> Is there any thoughts on this? I will help if needed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: >>>>>>>>>> the attributes we need could have setters in Ethumb.h or >>>>>>>>>> Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to >>>>>>>>>> access canvas and all, then move plugins to use it instead. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> I've just added some getters to Ethumb API. I think they are enough >>>>>>>>> (at least to my plugins), but let me know if you need any other. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> maybe this is the right thread to brings this up: >>>>>>>> >>>>>>>> could be a good idea to have a some sort of generic getter/setter that >>>>>>>> sets properties for plugins to look at. Instead of having >>>>>>>> ethumb_video_time_get|set, and the document page equivalent, it would be >>>>>>>> better to have ethumb_property_get|set or something of that sort, so >>>>>>>> that plugins can be able to obtain other properties that could be >>>>>>>> useful, without adding more setters and getters. This would also make >>>>>>>> the video_time and document_page functions obsolete. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I agree. I only have made these video_time and document_page functions >>>>>>> because it was simpler than having a generic property get/set >>>>>>> function, and since I was not planning to write newer plugins soon, it >>>>>>> wasn't really necessary. >>>>>>> >>>>>>> But maybe it's time to do it now. I'll take a look at it soon, just >>>>>>> finishing the client/server stuff and some changes on ethumb lib >>>>>>> itself. >>>>>>> >>>>>>> >>>>>> >>>>>> I disagree as this would defeat the purpose of plugins implementing a >>>>>> set of features. For example, if you start to make it open, >>>>>> applications would need to know deep into plugins, and that's not >>>>>> good. By forcing a explicit api we can stop and think about stuff, how >>>>>> to unify and be consistent. Otherwise applications will start to use >>>>>> emotion plugin on frames and xine plugin on time and mplayer plugins >>>>>> on tick based, defeating the purpose of the whole thing. So far we did >>>>>> document/paging and video, if you need new kind of feature, just say, >>>>>> let's think about it and design a good system, it might help existing >>>>>> stuff as well. >>>>>> >>>>>> >>>>> >>>>> I disagree with this. Its entirely up to the plugin to decide what >>>>> features it can support. Just because the current API covers two cases, >>>>> doesn't mean that you're safe. I can think of a few other properties >>>>> besides frame or document page for plugins, and I'm sure other people >>>>> might think of others as well. >>>>> >>>>> >>>> >>>> As you can imagine I disagree with that. First, the idea with plugins >>>> was to transparently handle media, not to specifically talk to one. >>>> Applications talk to thumbnailer and say "get me a visual >>>> representation of this file", and you specify some properties you'd >>>> like. Actually these properties should be guessed, but it's too >>>> difficult to guess right so we're giving hints. For example, if it was >>>> easy to avoid black screens and producer's logo/introduction from >>>> videos without wasting too much cpu time, we'd not even specify video >>>> properties. Same for documents, if we can find a good heuristics to >>>> avoid cover/empty/index pages, we could avoid these properties at all. >>>> Remember we're doing a thumbnailer, not a general purpose image >>>> resizing framework, the main goal is to make it easy to generate >>>> visual representation of files, not to replace gimp/imagemagick. >>>> >>>> And as I said, these properties are hints, of course plugins might not >>>> implement it. But when plugins implement, they have a rule of what to >>>> implement. Example, we know video have couple of properties with well >>>> known meaning. Generally we should not even specify such properties, >>>> but if we do (to overcome technical problems), we might present user >>>> with an interface to set such programs, even visually as Playstation3 >>>> do for video, you know the parameters you need to set. If we start to >>>> let it too loose we'll have to force apps to query installer plugins, >>>> then their properties and then try to map these to ui. Xine and others >>>> tried to do such a generic property-ui mapper and it sucks hard. >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> There should be no reason to limit what >>>>> plugins support by hard-coding what properties any potential plugins >>>>> should have. >>>>> >>>>> >>>> >>>> I really believe it's not a limitation, it's just forcing us to think, >>>> design and implement in central place. It will avoid fragmentation and >>>> help system overall. We tried to design it to fit cases we imagined, >>>> but if you really think of extra parameters, write them in a wiki and >>>> let us know, let's discuss and they'll go into the public api. This >>>> helps everybody. >>>> >>>> >>>> >>>> >>>>> >>>>> And if they are properly documented and there's even slight >>>>> coordination, I doubt that the scenario you showed would surface. >>>>> >>>>> >>>> >>>> This is the same as saying "plugins will write to a memory address >>>> that is docummented" (same process usage, regular ethumb api), or >>>> "plugins will register a dbus interface on their own to handle >>>> specific properties" (client-server api). Think about these, they're >>>> really ugly solutions, aren't they? But that's exactly what you're >>>> asking for, but dressed in the form of a api method. >>>> >>>> >>>> >>>> >>>>>> >>>>>> As for "generic" property, it would be as hard as the current >>>>>> implementation, instead of giving a single parameter and changing the >>>>>> value in structure, just give two and append to a list. But please >>>>>> don't do it, it will harm more than help the project. >>>>>> >>>>>> >>>>> >>>>> you can also use variable arguments to add as many properties in one go >>>>> as you need. >>>>> >>>>> >>>> >>>> that's syntax sugar, it's easy. I'm more concerned with the system >>>> usefulness of such thing. >>>> >>>> >>>> >>> >>> Well I like their idea and think they should give it a shot >>> and see what they can come up with. You're being overly picky >>> here in the name of some abstarct notion of 'quality control' >>> and what it's really amounting to is restriction and limitation. >>> The notion of having these plugins somehow being able to >>> use each other isn't all that big an impact here since most of >>> these would be one-time shots, not 30-times-per-sec deals.. and >>> you and raster actually wanted such a filters-pipeline in evas, >>> so it's odd you're against a similar capability here. >>> But even if these plugins don't evolve into such a system, >>> what they're proposing as a generic 'property/value' api for >>> controlling pluging states is very useful for having generic/ >>> loadable plugins.. rather than being restricted to some fixed >>> set of them with built-in special-purpose state api functions >>> for just this or that known or built-in plugin. >>> >>> There's a lot that can be done.. but not if arbitrary restrictins >>> are kept in the name of some fixed functionality that you happen >>> to want right now or some ideal notion that you can pick the >>> best centralized design that will cover all that's interesting. >>> >>> I'd say let Viktor and Rafael use their imagination and skills >>> and let them try and experiment and do their thing here. :) >>> >> >> As I said we have a purpose for doing such Ethumb and we need to >> remember about it. We're not restricting one's capabilities in doing >> whatever he wants, evas is always there, everyone is free to write >> whatever stuff wanted, but in order to keep things manageable we need >> to balance features and restrictions and I think this is a good trade >> off. >> >> > > Evas is evas, this is its own lib for generating "thumbs". > Some of that can have built-in cases that are important, but > there's no a priori need to limit things to that. why do you insist that requiring people to think about requirements and how to solve them properly is to limit things? I'm not limiting functionality, I'm just asking for input on what's missing and then think how to improve it. And by functionality I mean thumbnail-generation related, not functionality of the library itself. (the end functionality, not the way to get to it). > As to balancing features vs. restrictions.. Sure, that's always > a given. But just why are your restrictions here soooo necessary > that all is lost with a more flexible plugin system? You even > mentioned something about it 'harming the project', tell me > exactly HOW that would 'harm' anything? I describe it already, we should think about things that could help not just your plugin, but all of them. Making it very loose we'll quickly end with plugins that don't share interfaces, or interfaces are not consistent. This harms the project. >> I'm still waiting to see concrete ideas of more ideas that can benefit >> most and not single special case. Really, there is always a balance of >> feature/configurability and ease of use. Evas is one example of such >> balance that I believe is good: it does not allow you to do >> everything, but the things that it allows you to do it does fast and >> it's very easy. If one want to do vector or direct pixel manipulation >> it's not the way to go, but if you want to do simple raster effects >> it's very powerful and easy. Gtk's TreeView/TreeStore is what I'd >> > > Nonsense. It's just as possible to do vector stuff as raster > stuff with evas, api wise. It's just a pain to support all the > various engines people have been adding (in particular the > 16bpp ones which you pushed for and now have no interest in > supporting), and also to work with its primitive internal engine > func api which was designed a long time ago for a quick and > limited set of abilities. This latter wouldn't be such a big deal > to change if again there were fewer engines. Where do you want to go with this? I keep reading you complaining about 16bpp engine, actually you're the only one that seems to not get it right. Even raster got to understand with its purpose and accepts it, but you keep pushing against it. The purpose of this engine was never to be complete (no gradients), or super-correct (no smooth scale, no render ops, ...), but to be fast and cover the basics that embedded world uses, you could consider it a subset. And there are people using it, just not myself. Cedric uses it with SDL, Vincent and Lars use it with WinCE. > There's no loss and large gains in having evas support vgfx > directly, as well as further filter and other gfx notions. It's > not a problem at all. There is a bit of other stuff at the canvas > level that needs redoing if one wants to support complex gfx > operations on arbitrary objects, and some of the problems there > are due to the way smart-objects were implemented at the canvas > level. But again, there's nothing that can't be done, and done > quite efficiently - far more so than most current gfx libs do. > > >> say is a bad balance, it allows you to do whatever you want, but it's >> very tricky to get right and the simplest table needs lots of work. I >> want to avoid having a thumbnail that can generate everything in every >> way but it's unmaintainable and awkward to use. >> >> And as I said, if you really want to experiment, try a global, mmap, >> file or export a dbus object to do that. It's as problematic, ugly but >> unleashes the power you want. If it proves to be good, we can absorb >> the idea in the main api. But I'm against fragmenting the >> application-thumbnailer relationship at this point. What we need are >> requirements, think about then and act. What we do not need is lots of >> special parameters growing out of nowhere and causing more headaches. >> Just imagine we add a generic name-value association, to do dbus we >> need to add way to serialize it, then to do configuration we need to >> add labels, descriptions, range and possible example usage, and at the >> end we have a complete me >> > > I'll leave it up to you and the others to come up with a good design > here... Can you do it? :) I did it already. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Jose G. <jos...@ju...> - 2009-05-22 22:11:56
|
Gustavo wrote: >>> .......... >>> >> Nonsense. It's just as possible to do vector stuff as raster >> stuff with evas, api wise. It's just a pain to support all the >> various engines people have been adding (in particular the >> 16bpp ones which you pushed for and now have no interest in >> supporting), and also to work with its primitive internal engine >> func api which was designed a long time ago for a quick and >> limited set of abilities. This latter wouldn't be such a big deal >> to change if again there were fewer engines. >> > > Where do you want to go with this? I keep reading you complaining > about 16bpp engine, actually you're the only one that seems to not get > it right. Even raster got to understand with its purpose and accepts > it, but you keep pushing against it. The purpose of this engine was > never to be complete (no gradients), or super-correct (no smooth > scale, no render ops, ...), but to be fast and cover the basics that > embedded world uses, you could consider it a subset. And there are > people using it, just not myself. Cedric uses it with SDL, Vincent and > Lars use it with WinCE. > > > It's not a 'subset', it's crap. And completely unnecessary. The return on their investment is a net negative, increasingly heavier and heavier over time. Time and effort spent on those 'engines' would've been *far* better spent in optimizing transform/sampling/compositing and 32->16 conversion, for the 'important' architectures. As to what Carsten feels now and/or earlier regarding these 'engines', only he can really say. Mind you there are too many engines period, it's just that these engines have one particular aspect to them: they introduce the 16bpp color space into input/src data, and doing so is what amounts to a destructive result. PS. Gradients are actually one of the few things that you *could* add fairly easily to these engines, and have them look decent. It's just about everything else that's a problem. > >> There's no loss and large gains in having evas support vgfx >> directly, as well as further filter and other gfx notions. It's >> not a problem at all. There is a bit of other stuff at the canvas >> level that needs redoing if one wants to support complex gfx >> operations on arbitrary objects, and some of the problems there >> are due to the way smart-objects were implemented at the canvas >> level. But again, there's nothing that can't be done, and done >> quite efficiently - far more so than most current gfx libs do. >> >> ____________________________________________________________ Save on Cell Phones. Click Now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTKdW2FZI7qLYUPD6yeCfNG6sFTd78OBF257Jd8iAktxS9932VJls8/ |
From: Gustavo S. B. <bar...@pr...> - 2009-05-22 23:45:34
|
On Sat, May 23, 2009 at 12:12 AM, Jose Gonzalez <jos...@ju...> wrote: > Gustavo wrote: > >>>> .......... >>>> >>> >>> Nonsense. It's just as possible to do vector stuff as raster >>> stuff with evas, api wise. It's just a pain to support all the >>> various engines people have been adding (in particular the >>> 16bpp ones which you pushed for and now have no interest in >>> supporting), and also to work with its primitive internal engine >>> func api which was designed a long time ago for a quick and >>> limited set of abilities. This latter wouldn't be such a big deal >>> to change if again there were fewer engines. >>> >> >> Where do you want to go with this? I keep reading you complaining >> about 16bpp engine, actually you're the only one that seems to not get >> it right. Even raster got to understand with its purpose and accepts >> it, but you keep pushing against it. The purpose of this engine was >> never to be complete (no gradients), or super-correct (no smooth >> scale, no render ops, ...), but to be fast and cover the basics that >> embedded world uses, you could consider it a subset. And there are >> people using it, just not myself. Cedric uses it with SDL, Vincent and >> Lars use it with WinCE. >> >> >> > > It's not a 'subset', it's crap. And completely unnecessary. Ok, you are right and the world is wrong. Canola is totally unusable in maemo without 16bpp engine. You can get noticeable speedups in openmoko as well. I'm pretty sure Cedric and WinCE guys can step in and say their experiences as well. And regarding crap, it's such a hard word to describe work that INdT paid me to do for more than 3 months. It's very optimized and measured, I'm pretty sure it's not crap. > The return on their investment is a net negative, increasingly > heavier and heavier over time. Ok, so negative that it enable one of the strongest advocate of EFL. Without Canola's marketing of EFL we would not have things like BlueMaemo (maemo/bluetooth remote control), the openmoko version of bluemaemo, Carman. Without Canola we'd have no Python-EFL that is did bring lots of developers to our platform, and probably would not have myself or the dozen guys that I pay to work on EFL. That said, better not write such stupid thing than write it "just in case". You're doing no help in the last 2 years or so, then you come to the project to start creating such stupid flamewars. > Time and effort spent on those 'engines' would've been *far* > better spent in optimizing transform/sampling/compositing and > 32->16 conversion, for the 'important' architectures. I don't know if you forgot on purpose or not, but I keep saying that's not JUST ABOUT THE FSCKING TRANSFORM, IT'S ABOUT THE AMOUNT OF DATA. 24bpp will consume 4 bytes per pixel (due alignment), 16bpp will consume 2 bytes, that's half of the data that you have to load, that's half data to saturate your memory bus, cache. And it's less data to operate on, you can do all R, G and B multiply by A in the same instruction (given some quality constraints that were good enough for users and even graphical designers accepted it). Sure it will use more shifts and masks, but that's almost for free in most ARM platforms. But go ahead, "show me the code" as we usually say. Prove me wrong, don't flame me wrong. > As to what Carsten feels now and/or earlier regarding these > 'engines', only he can really say. > > Mind you there are too many engines period, it's just that > these engines have one particular aspect to them: they introduce > the 16bpp color space into input/src data, and doing so is what > amounts to a destructive result. You can easily ignore that, you did so for gradient2. There is no YUV->RGB (video/emotion), there is no gradient, there is no smooth scale. You're not forced to implement such. I doubt you have not finished a fast gradient2 on software/32 or gl because of software/16. > PS. > Gradients are actually one of the few things that you *could* > add fairly easily to these engines, and have them look decent. > It's just about everything else that's a problem. Why care about things that nobody cares? I worked with over dozen designers and none could think of use of single gradients. They usually want layers or semi transparent and radial and all you can imagine, you'll not be able to render that during runtime, specially on such devices. And even if you're able to, you don't need to. And given the absurdly slow code in gradient for software32 that relies on sin/cos/whatever is not present in systems without FPU, we're talking about a dead end. If you ask me, I'd actually add an option to disable gradient build altogether to save space on embedded devices that will not use it. I guess this thread is pretty over, things went really out of control. People were arguing about ethumb and we ended fighting about stupid stuff. I still hope that Viktor did not give up on trying to come with Ethumb/plugins requirements, I'd really like to know what is missing so we can think, design and implement a good platform. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Jose G. <jos...@ju...> - 2009-05-23 04:54:51
|
You seem to be taking this as a judgment on the quality of your work on your soft16 engines whereas if you stopped you'd realize that I'm addressing all rendering engines that use 16bpp data in their gfx pipeline. In this day and age, this is a disaster for anything that wants to grow towards building "richer" user interfaces. Whatever these devices, they would ultimately be much better served with their software stacks/dev-frameworks investing in enabling 'richer' guis and optimizing things for their systems that can allow for such 'rich' graphical experiences. The benefits of something like the moderate speed gains from a 16bpp gfx pipeline is only seen when one imposes large restrictions on what can be done. If this also becomes a limiting or constraining factor in what your gui libs are allowed to support, then you have a serious problem brewing. According to you: "Evas is one example of such balance that I believe is good: it does not allow you to do everything, but the things that it allows you to do it does fast and it's very easy. If one want to do vector or direct pixel manipulation it's not the way to go.." If we buy into this logic, then evas is just perfectly balanced as is and doesn't need anything else.. Why then would I or anyone spend time developing anything further gfx wise? As for the rest of your tirade on gradients or me or whatnot.. I'll leave that up to you to have the final word. :) >>>>> .......... >>>>> >>>>> >>>> Nonsense. It's just as possible to do vector stuff as raster >>>> stuff with evas, api wise. It's just a pain to support all the >>>> various engines people have been adding (in particular the >>>> 16bpp ones which you pushed for and now have no interest in >>>> supporting), and also to work with its primitive internal engine >>>> func api which was designed a long time ago for a quick and >>>> limited set of abilities. This latter wouldn't be such a big deal >>>> to change if again there were fewer engines. >>>> >>>> >>> Where do you want to go with this? I keep reading you complaining >>> about 16bpp engine, actually you're the only one that seems to not get >>> it right. Even raster got to understand with its purpose and accepts >>> it, but you keep pushing against it. The purpose of this engine was >>> never to be complete (no gradients), or super-correct (no smooth >>> scale, no render ops, ...), but to be fast and cover the basics that >>> embedded world uses, you could consider it a subset. And there are >>> people using it, just not myself. Cedric uses it with SDL, Vincent and >>> Lars use it with WinCE. >>> >>> >>> >>> >> It's not a 'subset', it's crap. And completely unnecessary. >> > > Ok, you are right and the world is wrong. Canola is totally unusable > in maemo without 16bpp engine. You can get noticeable speedups in > openmoko as well. I'm pretty sure Cedric and WinCE guys can step in > and say their experiences as well. > > And regarding crap, it's such a hard word to describe work that INdT > paid me to do for more than 3 months. It's very optimized and > measured, I'm pretty sure it's not crap. > > > >> The return on their investment is a net negative, increasingly >> heavier and heavier over time. >> > > Ok, so negative that it enable one of the strongest advocate of EFL. > Without Canola's marketing of EFL we would not have things like > BlueMaemo (maemo/bluetooth remote control), the openmoko version of > bluemaemo, Carman. Without Canola we'd have no Python-EFL that is did > bring lots of developers to our platform, and probably would not have > myself or the dozen guys that I pay to work on EFL. > > That said, better not write such stupid thing than write it "just in > case". You're doing no help in the last 2 years or so, then you come > to the project to start creating such stupid flamewars. > > > >> Time and effort spent on those 'engines' would've been *far* >> better spent in optimizing transform/sampling/compositing and >> 32->16 conversion, for the 'important' architectures. >> > > I don't know if you forgot on purpose or not, but I keep saying that's > not JUST ABOUT THE FSCKING TRANSFORM, IT'S ABOUT THE AMOUNT OF DATA. > 24bpp will consume 4 bytes per pixel (due alignment), 16bpp will > consume 2 bytes, that's half of the data that you have to load, that's > half data to saturate your memory bus, cache. And it's less data to > operate on, you can do all R, G and B multiply by A in the same > instruction (given some quality constraints that were good enough for > users and even graphical designers accepted it). Sure it will use more > shifts and masks, but that's almost for free in most ARM platforms. > > But go ahead, "show me the code" as we usually say. Prove me wrong, > don't flame me wrong. > > > >> As to what Carsten feels now and/or earlier regarding these >> 'engines', only he can really say. >> >> Mind you there are too many engines period, it's just that >> these engines have one particular aspect to them: they introduce >> the 16bpp color space into input/src data, and doing so is what >> amounts to a destructive result. >> > > You can easily ignore that, you did so for gradient2. There is no > YUV->RGB (video/emotion), there is no gradient, there is no smooth > scale. You're not forced to implement such. I doubt you have not > finished a fast gradient2 on software/32 or gl because of software/16. > > > >> PS. >> Gradients are actually one of the few things that you *could* >> add fairly easily to these engines, and have them look decent. >> It's just about everything else that's a problem. >> > > Why care about things that nobody cares? I worked with over dozen > designers and none could think of use of single gradients. They > usually want layers or semi transparent and radial and all you can > imagine, you'll not be able to render that during runtime, specially > on such devices. And even if you're able to, you don't need to. And > given the absurdly slow code in gradient for software32 that relies on > sin/cos/whatever is not present in systems without FPU, we're talking > about a dead end. > > If you ask me, I'd actually add an option to disable gradient build > altogether to save space on embedded devices that will not use it. > > I guess this thread is pretty over, things went really out of control. > People were arguing about ethumb and we ended fighting about stupid > stuff. I still hope that Viktor did not give up on trying to come with > Ethumb/plugins requirements, I'd really like to know what is missing > so we can think, design and implement a good platform. > > ____________________________________________________________ Compete with the big boys. Click here to find products to benefit your business. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTI97zKj35EYpMbR3NLeVHPmf7v0RiFnuLqt4dX2v7IdRTXFytgoEY/ |