On Tue, May 2, 2017 at 8:02 PM, Daniel Prager <daniel.a.pra...@gmail.com> wrote:
> Hi Ju > > Interesting results. Did you run the Contract Profiler tool? [ > http://docs.racket-lang.org/contract-profile/] > > I think it's fairly well understood that the contract-induced performance > costs across the typed / untyped boundary can be severe. > No, I didn't run the Contract Profiler tool. I just wanted to optimize it, the weirdest thing I found is, the total time is much larger then the sum of the in-function `time`s, I guess all bitmaps are checked one by one by the contract system, they are all objects. Last time I mentioned the flomap, I said "You need to convert the flomap struct into a bitmap% instance when drawing", the main reason is that nobody seems to maintain the images-lib, and it's Bitmap% is not the standard one since it exists before typed class is available, therefore the `flomap->bitmap` will simply fail due to the contract error. There is a pull request for it, but still has not been merged since 2015. [ https://github.com/racket/images/pull/2] > BTW: At the back of my mind is the thought that the performance one could > achieve on these kinds of benchmarks would go up ridiculously by pushing > the work to a GPU. > Yeah, some games shipped with the main distribution are written in racket-wrapped OpenGL. Despite the totally different APIs, you can try real time rendering algorithms without worrying about the performance. In fact, I am hesitating too, I have already finished the computational model of the CSS engine, but not sure whether the GUI part should be implemented with OpenGL or not. Designing application as a Game UI developer is fun, but meanwhile I do not have much time to do that. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
