Re: [Rails-devel] 18EU: Background Map submission (revised version)

[brett l. <bre...@gm...>]

I have a feeling that old drawing code is just incredibly inefficient
and adding the map might tip it over into unusability. I'll blame my
limited understanding of AWT. It's probably time to refactor a bunch
of that. ;-)

Some possible places to look for improvements:

1.  It looks like we're still using AffineTransforms on the rasterized
version of the hex. (A remnant from when we were still using GIF-based
tiles. There is likely a way to get Batik to manipulate the
vector-based format prior to rasterization in a more efficient way.

Once we rasterize the image, we should avoid changing it.

2. There may be a better way to load the map than with BufferedImageTranscoder.

3. Profiling the code will likely help quickly locate the reason
drawing is slow. It looks like there's some profiling plugins
available for Eclipse ( http://www.eclipse.org/tptp/home/downloads/ ),
but I'm not sure how well they work.

Though, simply adding a few debugging statements starting at paint()
or paintComponent() might be sufficient to see how often they're
called in a single rendering. It might just be a simple issue of
repainting the window more often than we really need to.

---Brett.



On Fri, Jun 3, 2011 at 9:02 AM, Erik Vos <eri...@xs...> wrote:
> OK, I have attached a patch file that includes all differences.  Hope it's not too big...
> The main part is a trimmed version of the 18EU map, with all empty borders removed (by Inkscape).
> I did that in the hope that it would help fixing the crash problem, but it didn't help at all.  But in any case I think it's better to avoid such empty borders.
>
> Erik.
>
>> -----Oorspronkelijk bericht-----
>> Van: brett lentz [mailto:bre...@gm...]
>> Verzonden: vrijdag 3 juni 2011 16:54
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] 18EU: Background Map submission (revised
>> version)
>>
>> On Fri, Jun 3, 2011 at 5:43 AM, Erik Vos <eri...@xs...> wrote:
>> > I would like to give other people a chance to play with this new
>> > stuff, but I'm not sure if I should commit my changes to the SVN
>> > trunk.  Perhaps we should create a  branch for this experimental
>> > feature (but I have no clue how to do that - I've never done
>> branching  before).
>> > On the other hand, I have already added a configuration property to
>> > completely suppress the use of SVG maps, so probably no harm would be
>> > done by putting this code into the trunk anyway.
>> >
>> > Suggestions?
>> >
>>
>> Post your implementation to the list as a set of diffs. Perhaps just a second
>> set of eyes can help spot the issue.
>>
>> > Erik.
>>
>> ---Brett.
>>
>> ------------------------------------------------------------------------------
>> Simplify data backup and recovery for your virtual environment with
>> vRanger.
>> Installation's a snap, and flexible recovery options mean your data is safe,
>> secure and there when you need it. Discover what all the cheering's about.
>> Get your free trial download today.
>> http://p.sf.net/sfu/quest-dev2dev2
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>