Re: [JPP-Devel] CVS to SVN Migration...Are we done yet?
Paul, Can you add the directories that you think are applicable? The Sunburned Surveyor On 6/19/07, Paul Austin <[EMAIL PROTECTED]> wrote: > One other thing, I think we should add some directories to svn:ignore > (such as build, or target (if people use maven)) so that people don't > accidentally commit their compiled sources. > > Paul > > Sunburned Surveyor wrote: > > I moved the [/tags] folder under [/core] as Paul had suggested. I > > don't think there were any other suggestions I missed, except for the > > plug-in folders, which we've discussed. > > > > Does anyone else see a reason why we can't start using the SVN > > repository? (I want to make sure I'm not forgetting something.) > > > > The Sunburned Surveyor > > > > - > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > ___ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] CVS to SVN Migration...Are we done yet?
On trunk and the current branch add the following, these will be copied if you branch or tag further target dist build log tmp .eclipse .settings Paul Sunburned Surveyor wrote: > Paul, > > Can you add the directories that you think are applicable? > > The Sunburned Surveyor > > On 6/19/07, Paul Austin <[EMAIL PROTECTED]> wrote: > >> One other thing, I think we should add some directories to svn:ignore >> (such as build, or target (if people use maven)) so that people don't >> accidentally commit their compiled sources. >> >> Paul >> >> Sunburned Surveyor wrote: >> >>> I moved the [/tags] folder under [/core] as Paul had suggested. I >>> don't think there were any other suggestions I missed, except for the >>> plug-in folders, which we've discussed. >>> >>> Does anyone else see a reason why we can't start using the SVN >>> repository? (I want to make sure I'm not forgetting something.) >>> >>> The Sunburned Surveyor >>> >>> - >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> ___ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >> - >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [pgadmin-support] Problem editing tables (geom columns)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (First of all sorry for cross-posting but I feel this is a matter that interests all recipients) Thread on pgadmin support: http://www.pgadmin.org/archives/pgadmin-support/2007-06/msg00046.php Hello Dave, This behavior (trying to show the entire geometry field) in Fedora Core 6, pgAdmin3 1.6.2, doesn't happen... In that scenario the geom field is simply shown blank. Nevertheless, if I recall it correctly, proj4, geos, postgis versions, in the above scenario, were older than the ones I'm using... So I wonder... could it be that pgadmin's code changed for showing large fields? Could one of proj4, geos, postgis code changed that really interferes with pgadmin3? IMHO, regardless of the scenario involved, the output for large geom fields should be suppressed in table edition... (as seen in the past) The current behavior hogs way too much processor time. I've tested with a micro-subset of my data (only one record with a small parish geometry) and it shows although the slowness is immediately apparent... Kind regards, Pedro Doria Meunier Dave Page wrote: > Dave Page wrote: >> Pedro Doria Meunier wrote: >>> I've seen in the known issues for ver 1.6.3 that there's a >>> problem with editing tables with long fields... >> Where do you see that? >> >>> Strangely enough I've used this version before with Fedora Core >>> 6 and there wasn't a problem with postgis tables :$ A long >>> work has already been done setting up Fedora 7 to my taste so >>> I'm really not too keen on downgrading to FC6... :-( >>> >>> So, I'm a bit lost here... Is this a GTK issue? What can I do >>> to fix this? >> Can you supply me a sample table and data to test with please? > > I've been playing with the data that Pedro supplied me offlist, and > the problem is basically that he has a geometry value (basically a > string) in a column of around 4MB. I think it's fairly safe to say > that we'd be lucky to find that any of the grid controls on any of > the platforms we support were happy with this amount of data in a > single cell - in testing on Windows for example, whilst it works, > it does slow to a crawl. > > I think the only sensible option would be to add an additional tab > to the sort/filter dialog to allow the data to be vertically > partitioned to exclude such columns. This isn't going to happen for > the next release though I'm afraid. > > Thoughts? > > Regards, Dave. > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Remi - http://enigmail.mozdev.org iD8DBQFGeWFf2FH5GXCfxAsRArySAKCeVIK5uzDEs+Q6ZS0A2Jye6c5h0ACeKlkf MqNA+rBORwi5Ko2x/rRV+Cc= =rOET -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] A new ThreadQueue
except the ones from pirol I am not really aware of other renderers...
but compatibility is (sometimes unfortunately) one of our goals
stefan
Sascha L. Teichmann schrieb:
> Hi Larry,
>
> this all fits together very well and I have
> a couple of comments/ideas. This is most radical one:
>
> Let me switch to "software designer mode" for a moment.
> (This is what my company is paying me for besides working
> with legacy code... ;-)
>
> We have actually two problems:
>
> 1 - We cannot determine exactly when a rendering
> has ended (successfully or not).
>
> This is important for e.g. printing and zooming+flashing.
>
> The 'wakeup' Runnable trick only works if all jobs are
> processed in a serial manner. It fails when DB or WMS layers
> are involved because these are processed truly parallel.
>
> What we really want is some kind of a reliable barrier
> mechanism that triggers certain things after a rendering.
> (unlocking a wait in the printing case and flashing in case of
> zoom to selection)
>
> 2 - We have a javax,swing.Timer in RenderingManager
> that triggers a repaint any x ms.
>
> To what value we should set x?
>
> A x too large makes the the GUI feels sluggish. x choosen too
> small costs a lot of performance. I've got interesting profiling
> numbers from JProbe that told me that the copyTo() stuff can
> take up to 25% of the rendering time when you set x too low.
>
> If we ask how we have to set x, we're asking the wrong question.
> The question should state:
>
> Has a renderer made enough progress to do a repaint?
>
> If the on screen differences between two repaints would be too
> small, why should we waste time to do a redraw? Only a significant
> change (say a quarter of features drawn more) is worth this expense.
> With a fixed scheduled timer you cannot test this efficiently.
>
> This has to be done in cooperation with the particular renderer.
>
> How to address these issues?
>
> In my "software designer" dreamland i would propose the following:
>
> 1 - Remove the fixed scheduled timer
>
> 2 - Change the Renderer interface (Gulp!)
>
> I would introduce an inner interface 'RenderingMaster':
>
> interface RenderingMaster {
> void doRepaint(Renderer thisRenderer);
> void renderingDone(Renderer thisRenderer, boolean success);
> }
>
> and change the signature of createRunnable() to:
>
> Runnable createRunnable(RenderingMaster master);
>
>The idea of this extra callback should be pretty obvious.
>Each time a renderer has produced a significant part of
>output it calls master.doRepaint(this). On the implementors
>side of RenderingMaster we can do a repaint.
>If a renderer finished its job it calls
>master.renderingDone(this, true). (false after canceling)
>On the implementors side of RenderingMaster we can do some
>reference counting and kick some listeners when all jobs are
>done.
>
>>From designer dreamland back to the reality of legacy code:
>
> I would estimate about 1-2 days of work to refactor the core code
> to use this new pattern + some testing.
>
> The real problem arises from the fact that there is a sky
> full of JUMPs and a lot of non-core Renderers out there.
> This modification would be a heavy one and I
> don't really dare to think about the consequences ...
>
> Things like mouse wheel zooming may profit from this change too.
> So I don't want to wipe off this idea.
>
> Any comments?
>
> Regards,
> Sascha
>
> PS: If you don't like it all I have some 'workaround' ideas too ...
>
> Larry Becker schrieb:
>> Hi Sascha,
>>
>>I have figured out what is different about rendering timing in
>> SkyJUMP and OpenJump. The randomly delayed drawing in OpenJump is
>> caused by the repaintTimer in RenderingManager. In OpenJump and JUMP it
>> is set to 1 second, and in SkyJUMP it is set to 400 ms. This makes
>> SkyJUMP rendering more responsive to support Mouse Wheel zooming,
>> although still somewhat random.
>>
>> When the number of items withing the current window for a given layer
>> falls below the maxFeatures threshold, the
>> simpleFeatureCollectionRenderer is used, otherwise
>> imageCachingFeatureCollectionRenderer is used. Image Caching implies
>> that we have to wait for the repaintTimer to expire before all of the
>> results of render operations are guaranteed to be copied on screen.
>> When image Caching is disabled, drawing is synchronized but unresponsive
>> because nothing appears on the screen until the end of the process.
>>
>> I'm not sure we can do anything about the repaintTimer's apparent
>> randomness. The whole point of having a repaint timer is to be
>> unsynchronized with the layer rendering process. Setting the timer
>> value to 400 ms seems to make it responsive enough for the
>> ZoomToSelectedItemsPlugIn. We'll need to do that anyway when mouse
>> wheel
Re: [JPP-Devel] Update on pluggable renderers...
SS, Do you have a simple example that you can share? I'm currently looking at a whole bunch of ways of allowing additional things to be pluggable in JUMP so will be interested in learning more. Paul Sunburned Surveyor wrote: > Just a note on my recent work on OpenJUMP's pluggable renderering > system. I have eliminated the need for an external text file > specifying custom renderers and the classes they paint. This > simplified my modifications to the RendererFactory class quite a bit, > and removed the problem of IOExceptions in both the RendererFactory > class and RenderingManager class. > > I am now using a technique designed in JUMP by Vivid Solutions that > allows pluggable renderers to be "plugged-in" using a normal JUMP > plug-in. An important improvement is that we will be able to plug-in > custom renderers for layerable objects, not just objects that get > painted above or below regular layerables. This will make experiments > and testing of different renderers for existing objects like Layers > much quicker. (This should appeal to Larry and other performance > freaks.) It will also allow for easy implementation of rendering for > new objects like stand alone labels, station labels, and > images/rasters. > > In essence this system will allow major changes to OpenJUMP's > rendering of any object, layerable or otherwise, with the installation > or removal of a single plug-in JAR! > > I've got the system nearly hammered out. I still need to create the > implementations for the GridRenderer, Scale Bar Renderer, > SelectionBackgroundRenderer, LineSelectionRenderer, > FeatureSelectionRenderer, and PartSelectionRenderer. > > Here are some of my notes on the system's design so far: > > InstallRendererFactoryToolPlugIn class replaces InstallRendererPlugIn. > InstallRendererFactoryToolPlugIn installs a RendererFactoryTool in > every RenderingManager instead of directly installing a Renderer in > each RenderingManager. (Previously you could only install Renderers > into the AboveLayerables collection or BelowLayerables collection of > renderers using the InstallRendererPlugIn class. You could not install > renderers for regular layerables using a plug-in. This has now > changed. You can install pluggable renderers for either regular > layerables or objects that should be painted above or below > layerables.) > > Steps to using the pluggable rendering system. > > [1] Define a custom Renderer implementation. > > [2] Define a IRendererFactoryTool that returns the custom Renderer > created in Step #1 when given a sample object or class name of the > object that it is meant to render. > > [3] Extend the InstallIRendererFactoryToolPlugIn class so that the > IRendererFactoryTool implementation created in Step #2 will be placed > in all RenderingManagers. (This is very simple. All you need to do in > the extended class is override the constructor to set the > IRendererFactoryTool instance, set two (2) boolean values indicating > if the renderer paints object above or below layerables, and set a > String with the class name of the objects your pluggable renderer will > paint. All the other work is taken care of by the default class > methods. > > [4] Create a Jar with the custom Renderer implementation, the > IRendererFactoryTool implementation, and the > InstallRendererFactoryToolPlugIn extension and drop it into OpenJUMP's > /ext folder." > > The Sunburned Surveyor > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Update on pluggable renderers...
Just a note on my recent work on OpenJUMP's pluggable renderering system. I have eliminated the need for an external text file specifying custom renderers and the classes they paint. This simplified my modifications to the RendererFactory class quite a bit, and removed the problem of IOExceptions in both the RendererFactory class and RenderingManager class. I am now using a technique designed in JUMP by Vivid Solutions that allows pluggable renderers to be "plugged-in" using a normal JUMP plug-in. An important improvement is that we will be able to plug-in custom renderers for layerable objects, not just objects that get painted above or below regular layerables. This will make experiments and testing of different renderers for existing objects like Layers much quicker. (This should appeal to Larry and other performance freaks.) It will also allow for easy implementation of rendering for new objects like stand alone labels, station labels, and images/rasters. In essence this system will allow major changes to OpenJUMP's rendering of any object, layerable or otherwise, with the installation or removal of a single plug-in JAR! I've got the system nearly hammered out. I still need to create the implementations for the GridRenderer, Scale Bar Renderer, SelectionBackgroundRenderer, LineSelectionRenderer, FeatureSelectionRenderer, and PartSelectionRenderer. Here are some of my notes on the system's design so far: InstallRendererFactoryToolPlugIn class replaces InstallRendererPlugIn. InstallRendererFactoryToolPlugIn installs a RendererFactoryTool in every RenderingManager instead of directly installing a Renderer in each RenderingManager. (Previously you could only install Renderers into the AboveLayerables collection or BelowLayerables collection of renderers using the InstallRendererPlugIn class. You could not install renderers for regular layerables using a plug-in. This has now changed. You can install pluggable renderers for either regular layerables or objects that should be painted above or below layerables.) Steps to using the pluggable rendering system. [1] Define a custom Renderer implementation. [2] Define a IRendererFactoryTool that returns the custom Renderer created in Step #1 when given a sample object or class name of the object that it is meant to render. [3] Extend the InstallIRendererFactoryToolPlugIn class so that the IRendererFactoryTool implementation created in Step #2 will be placed in all RenderingManagers. (This is very simple. All you need to do in the extended class is override the constructor to set the IRendererFactoryTool instance, set two (2) boolean values indicating if the renderer paints object above or below layerables, and set a String with the class name of the objects your pluggable renderer will paint. All the other work is taken care of by the default class methods. [4] Create a Jar with the custom Renderer implementation, the IRendererFactoryTool implementation, and the InstallRendererFactoryToolPlugIn extension and drop it into OpenJUMP's /ext folder." The Sunburned Surveyor - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Update on pluggable renderers...
Paul, I'm afraid I'm not quite ready to meet your request. Are you looking for actual code? Or are you more interested in a narrative of how things will work? I think the key concept to my pluggable rendering system is this: In the initial design I could not find a way to allow plug-ins to access the TaskFrames or any of the componenets associated and/or contained by the TaskFrame. (In this case it was the RenderingManager stored in the TaskFrame.) The basic root cause of this problem is that the initialization method of the plug-in interface is only called when OpenJUMP loads, while additional TaskFrames can be created at any time after program start-up. I found the solution to this problem encapsulated in the InstallRendererPlugIn class. Vivid Solutions was able to add a listener to the WorkbenchFrame that was called each time a TaskFrame is added. I thought this was a very ingenious solution to the design problem. The only thing I don't like about it is the fact that it violates the model/user interface separation principle. I think the correct way to do it would have been to add a listener for the creation of a Task object iteself, not a TaskFrame which is the GUI component representing a task. But maybe this is O.K. since rendering is related to the program GUI. I think I would have done it differently though. Still, I'm not going to try to tweak things that much over a design principle. What has been done will work for my pluggable rendering system. The Sunburned Surveyor P.S. - I can send my pluggable rendering system code to you, but it is only about 90% complete. On 6/20/07, Paul Austin <[EMAIL PROTECTED]> wrote: > SS, > > Do you have a simple example that you can share? I'm currently looking > at a whole bunch of ways of allowing additional things to be pluggable > in JUMP so will be interested in learning more. > > Paul > > Sunburned Surveyor wrote: > > Just a note on my recent work on OpenJUMP's pluggable renderering > > system. I have eliminated the need for an external text file > > specifying custom renderers and the classes they paint. This > > simplified my modifications to the RendererFactory class quite a bit, > > and removed the problem of IOExceptions in both the RendererFactory > > class and RenderingManager class. > > > > I am now using a technique designed in JUMP by Vivid Solutions that > > allows pluggable renderers to be "plugged-in" using a normal JUMP > > plug-in. An important improvement is that we will be able to plug-in > > custom renderers for layerable objects, not just objects that get > > painted above or below regular layerables. This will make experiments > > and testing of different renderers for existing objects like Layers > > much quicker. (This should appeal to Larry and other performance > > freaks.) It will also allow for easy implementation of rendering for > > new objects like stand alone labels, station labels, and > > images/rasters. > > > > In essence this system will allow major changes to OpenJUMP's > > rendering of any object, layerable or otherwise, with the installation > > or removal of a single plug-in JAR! > > > > I've got the system nearly hammered out. I still need to create the > > implementations for the GridRenderer, Scale Bar Renderer, > > SelectionBackgroundRenderer, LineSelectionRenderer, > > FeatureSelectionRenderer, and PartSelectionRenderer. > > > > Here are some of my notes on the system's design so far: > > > > InstallRendererFactoryToolPlugIn class replaces InstallRendererPlugIn. > > InstallRendererFactoryToolPlugIn installs a RendererFactoryTool in > > every RenderingManager instead of directly installing a Renderer in > > each RenderingManager. (Previously you could only install Renderers > > into the AboveLayerables collection or BelowLayerables collection of > > renderers using the InstallRendererPlugIn class. You could not install > > renderers for regular layerables using a plug-in. This has now > > changed. You can install pluggable renderers for either regular > > layerables or objects that should be painted above or below > > layerables.) > > > > Steps to using the pluggable rendering system. > > > > [1] Define a custom Renderer implementation. > > > > [2] Define a IRendererFactoryTool that returns the custom Renderer > > created in Step #1 when given a sample object or class name of the > > object that it is meant to render. > > > > [3] Extend the InstallIRendererFactoryToolPlugIn class so that the > > IRendererFactoryTool implementation created in Step #2 will be placed > > in all RenderingManagers. (This is very simple. All you need to do in > > the extended class is override the constructor to set the > > IRendererFactoryTool instance, set two (2) boolean values indicating > > if the renderer paints object above or below layerables, and set a > > String with the class name of the objects your pluggable renderer will > > paint. All the other work is taken care of by the default class > > methods. > > > > [4] Create
Re: [JPP-Devel] A new ThreadQueue
Thanks Stefan. We appreciate other voices in what was becoming a dialog.
Hi Sascha,
I agree with your two problems as stated.
1 - We cannot determine exactly when a rendering
has ended (successfully or not).
2 - We have a javax,swing.Timer in RenderingManager
that triggers a repaint any x ms.
I'm not sure that changing the repaint timer setting from 1000 to 400
affects performance significantly. My benchmarks show a 3% increase in
render time for burlulc. I'm not sure if that will be true for all
platforms and CPUs. There could be some advantage from my Dell's P4
hyper-threading here. I'll have to do more tests on a single CPU to be
sure. I did drop the time to 40 ms and got a 22% increase. At that level,
Jon's comment about too little happening each repaint rang true.
A 400 ms repaint timer doesn't solve the problem, but it makes it bearable
for zoom to selected. I can't speak to how this affects the printing
plugins. For databases and WMSLayers, it isn't the solution. Are the
printing plugins working around this problem now by long delays or what?
I'm trying to assess the impact of not fixing this issue right now. I don't
want to minimize the problem, but I see other more pressing issues of speed
and usability that need my attention right now. I need to work on the speed
of Task Loading, and I found a new issue today working with very large
datasets. It takes a _very_ long time to delete 50,000 objects. I see big
gains with minimal effort expended in these areas.
So Sascha, what is your other suggestion for a less radical solution?
regards,
Larry
On 6/20/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
except the ones from pirol I am not really aware of other renderers...
but compatibility is (sometimes unfortunately) one of our goals
stefan
Sascha L. Teichmann schrieb:
> Hi Larry,
>
> this all fits together very well and I have
> a couple of comments/ideas. This is most radical one:
>
> Let me switch to "software designer mode" for a moment.
> (This is what my company is paying me for besides working
> with legacy code... ;-)
>
> We have actually two problems:
>
> 1 - We cannot determine exactly when a rendering
> has ended (successfully or not).
>
> This is important for e.g. printing and zooming+flashing.
>
> The 'wakeup' Runnable trick only works if all jobs are
> processed in a serial manner. It fails when DB or WMS layers
> are involved because these are processed truly parallel.
>
> What we really want is some kind of a reliable barrier
> mechanism that triggers certain things after a rendering.
> (unlocking a wait in the printing case and flashing in case of
> zoom to selection)
>
> 2 - We have a javax,swing.Timer in RenderingManager
> that triggers a repaint any x ms.
>
> To what value we should set x?
>
> A x too large makes the the GUI feels sluggish. x choosen too
> small costs a lot of performance. I've got interesting profiling
> numbers from JProbe that told me that the copyTo() stuff can
> take up to 25% of the rendering time when you set x too low.
>
> If we ask how we have to set x, we're asking the wrong question.
> The question should state:
>
> Has a renderer made enough progress to do a repaint?
>
> If the on screen differences between two repaints would be too
> small, why should we waste time to do a redraw? Only a significant
> change (say a quarter of features drawn more) is worth this expense.
> With a fixed scheduled timer you cannot test this efficiently.
>
> This has to be done in cooperation with the particular renderer.
>
> How to address these issues?
>
> In my "software designer" dreamland i would propose the following:
>
> 1 - Remove the fixed scheduled timer
>
> 2 - Change the Renderer interface (Gulp!)
>
> I would introduce an inner interface 'RenderingMaster':
>
> interface RenderingMaster {
> void doRepaint(Renderer thisRenderer);
> void renderingDone(Renderer thisRenderer, boolean success);
> }
>
> and change the signature of createRunnable() to:
>
> Runnable createRunnable(RenderingMaster master);
>
>The idea of this extra callback should be pretty obvious.
>Each time a renderer has produced a significant part of
>output it calls master.doRepaint(this). On the implementors
>side of RenderingMaster we can do a repaint.
>If a renderer finished its job it calls
>master.renderingDone(this, true). (false after canceling)
>On the implementors side of RenderingMaster we can do some
>reference counting and kick some listeners when all jobs are
>done.
>
>>From designer dreamland back to the reality of legacy code:
>
> I would estimate about 1-2 days of work to refactor the core code
> to use this new pattern + some testing.
>
> The real problem arises from the fact that there is a sky
> full of JUMPs and a lot of non-core Renderers out
[JPP-Devel] Another note on pluggable rendering...
After the design of the pluggable rendering system there will no longer be any special "magic" needed to add a Renderer for objects that are painted above or below Layerables. These Renderers will be added in the same way as Renderers for Layerables. To users of the Pluggable Rendering System API there will be no difference between adding a pluggable renderer for Layerable objects and for objects that go above and below layerable objects. The logic that distinguishes between the two types of Renderers will now be handled in the methods of the InstallIRendererFactoryToolPlugIn class. This will mean that we can eliminate the Renderer.Factory class for Renderers of objects painted above and below Layerable objects. I am also modifying the containers for the ContentIDs and/or objects that are painted above or below Layerable objects so that the porgrammer using the pluggable rendering system API can control and manipulate the order in which these objects are painted much in the way that we allow the user to control the order in which Layerables are painted via the LayerTreeView. I don't think that this is possible under our current system. (I'm sure I'll have really busted a few things in the rendering system when I get done with these changes.) :] I will try to post some notes about things I learned about the RenderingManager class and the rendering system in general on the wiki tonight. The Sunburned Surveyor - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] A new ThreadQueue
Hi! Larry Becker schrieb: > Thanks Stefan. We appreciate other voices in what was becoming a dialog. We're talking about a very small technical detail here so nobody who is only concerned in the 'big plot' is willing to follow. My fault. I should talk more about brand new, cool, and hyper-ultra features for the end users ... > I agree with your two problems as stated. > 1 - We cannot determine exactly when a rendering > has ended (successfully or not). > 2 - We have a javax,swing.Timer in RenderingManager > that triggers a repaint any x ms. First of all let me state that we are not talking about 'A new ThreadQueue' any more. The problems we discussing now exist with the old and the new one. See below. My main goal in this thread was to bring on a new ThreadQueue. Are we through with this? If yes, I will commit it. > I'm not sure that changing the repaint timer setting from 1000 to 400 > affects performance significantly. My benchmarks show a 3% increase in > render time for burlulc. I'm not sure if that will be true for all > platforms and CPUs. There could be some advantage from my Dell's P4 > hyper-threading here. I'll have to do more tests on a single CPU to be > sure. I did drop the time to 40 ms and got a 22% increase. At that > level, Jon's comment about too little happening each repaint rang true. Sorry Larry, setting the the value to 400ms does not solve the problem on my lower end machine. The flash is regularly omitted if I zoom to smaller scales. All the tweaking you are suggesting seems to scale with your horse power (only). > A 400 ms repaint timer doesn't solve the problem, but it makes it > bearable for zoom to selected. I can't speak to how this affects the > printing plugins. For databases and WMSLayers, it isn't the solution. Exactly. And you may be supprised: there are people out there who want to print WMS layers too. Ask Jukka! > Are the printing plugins working around this problem now by long delays > or what? The Print/Layout plug-in offers an option to set a wait time for this kind of layers with a comment like "Sorry dear user, we aren't capable to figure out how long it may take to print this layer. Try several value. Do some nested intervals. Do a little trial and error." IMHO this isn't very cool. Same for zooming. To avoid expensive data import into the Print/Layout plug-in we offer the opportunity to insert previews (screen shots) of the map. Later when the real print is done the data needs to be extracted from the GIS. This involves a zooming to a bookmarked position. Zooming is not reliable. So we have the same waiting options here with the same cheesy comment "Sorry, dear user ..." I can live with this. As I said a long time ago at the very beginning of this thread: I can explain this to customers, I'm able proof the quirks and I'm also able to show possible solutions. The real interesting question (to me) is: Is it possible in OpenJUMP to correct little design flaws like this? Even if we have to bend the original design a bit? I'll have a keen look at Landons pluggable renderer stuff ... > I'm trying to assess the impact of not fixing this issue right now. I > don't want to minimize the problem, but I see other more pressing issues > of speed and usability that need my attention right now. I need to work > on the speed of Task Loading, and I found a new issue today working with > very large datasets. It takes a _very_ long time to delete 50,000 > objects. I see big gains with minimal effort expended in these areas. This is fine to me and I appreciate this. I have other things for the 'big plot'(tm) in the pipe too (the improved WMS support e.g). I'm the last who wants to throttle you with unimportant things. :-) > So Sascha, what is your other suggestion for a less radical solution? Larry, the modifications I'd suggested were very easy to implement. I removed the Timer in the RenderingManager, adjusted the Renderers and made the RenderingManager a RenderingMaster which is able to track the rendering. Under [1] you find the according src tree. I left out the docs/libs/dlls and so on. If one is interested look at Renderer, RenderingManager, ImageCachingRenderer, ImageCachingFeatureCollectionRenderer and ZoomToSelectedItemsPlugIn. Now the less radical solution: Start a new thread in ZoomToSelectedItemsPlugIn and let it sleep for 400ms before you do the flash. Something like this has to be done in all cases because the ThreadQueue tells you about the end of a rendering thread and not if the panel is ready for a flash. This has to do with repaint()/copyTo() stuff which has to be done afterwards and takes some (machine dependent) time too. regards, Sascha [1] http://intevation.de/~teichmann/openjump/openjump-src-renderer-mod.tar.bz2 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version
[JPP-Devel] Some help with Java I/O...
I had a few minutes after my wife went to bed tonight to work on my FeatureCache. I'm currently writing code for the BOFFFeatureWriter. In this class I have a method that sets up a DataOutputStream so I can write bytes representing the feature to a binary file. I need to see if a binary file representing the Feature already exists. If it does exist I need to delete it so the file can be "overwritten". (In the FeatureCache each Feature is saved to a binary file that has a unique name. This unique name is the same as the unique number that identifies the Feature object. I don't want to append the data being written to an existing file, nor do I want to have two (2) files with different names representing the same Feature object.) I haven't written a lot of Java I/O code, so I was hoping one of you more experienced developers might look at the method I wrote that prepares the DataOutputStream to see if I had any obvious mistakes or bugs. I have pasted the method statements in the attached text file. Thank you for the help. The Sunburned Surveyor method_statements Description: Binary data - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Some help with Java I/O...
You wrote
File dataStorageDirectory = new File(argPath);
File toWrite = new File(argPath + argFileName);
Do you intent to write
File dataStorageDirectory = new File(argPath);
File toWrite = new File(argPath, argFileName);
',' instead of '+' for appending a filename to the path?
See JavaDoc for File(String parent, String child).
BTW: If you open an existing file for writing again it
will be overwritten if you write to it. Run the
following to see what I mean:
import java.io.*;
public class Test
{
public static void main(String [] args) throws IOException {
String filename = "test.txt";
File file = new File(filename);
FileOutputStream out = new FileOutputStream(filename);
byte msg [] = new byte[10];
out.write(msg);
out.close();
System.out.println("first: " + file.length());
out = new FileOutputStream(filename);
msg = new byte [1];
out.write(msg);
out.close();
System.out.println("second: " + file.length());
}
}
- Sascha
Sunburned Surveyor schrieb:
> I had a few minutes after my wife went to bed tonight to work on my
> FeatureCache. I'm currently writing code for the BOFFFeatureWriter. In
> this class I have a method that sets up a DataOutputStream so I can
> write bytes representing the feature to a binary file.
>
> I need to see if a binary file representing the Feature already
> exists. If it does exist I need to delete it so the file can be
> "overwritten". (In the FeatureCache each Feature is saved to a binary
> file that has a unique name. This unique name is the same as the
> unique number that identifies the Feature object. I don't want to
> append the data being written to an existing file, nor do I want to
> have two (2) files with different names representing the same Feature
> object.)
>
> I haven't written a lot of Java I/O code, so I was hoping one of you
> more experienced developers might look at the method I wrote that
> prepares the DataOutputStream to see if I had any obvious mistakes or
> bugs. I have pasted the method statements in the attached text file.
>
> Thank you for the help.
>
> The Sunburned Surveyor
>
>
>
>
> -
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
>
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
