Re: [wxhaskell-devel] using graphicscontext inside a paint event

[Kristof B. <kr...@re...>]

I have made some changes on my github fork, which I like better:

paintRaw now has type:
paintRaw  :: Event w (PaintDC () -> Rect -> [Rect] -> IO ())

So you can use "graphicsContextCreate paintDC".
I removed my new handler paintRawContext, since it isn't needed.
This should be mostly compatible with old code, since (PaintDC ())
should work with (DC a)

I currently have:
paintContext :: Event w (DC () -> GraphicsContext () -> Rect -> IO ())

Maybe it would be better to have the following handler?
paintGcdc :: Event w (GCDC () -> Rect -> IO ())

I have read that gcdc implements anti-aliasing, but I didn't try it yet...

I also duplicated the code of dcBufferWithRefEx to take an extra 
graphicscontext
argument, but I'd like to find a way to tidy that up...

Regards,
Kristof

On 09-03-14 23:21, Kristof Bastiaensen wrote:
> I implemented this idea of adding a new paint event handler:
> https://github.com/kuribas/wxHaskell/commit/a779f8e7e34fe03822f380c4cdd1aa8a9ed97e81
>
> I could be tidied up, because I duplicated a lot of code...
>
> Regards,
> Kristof Bastiaensen
>
> On 09-03-14 20:10, Kristof Bastiaensen wrote:
>> Hi,
>>
>> I need to use a graphicpath to draw bezier curves, but wxhaskell doesn't
>> allow
>> me to create a graphicscontext from a paint event.
>>
>> The reason is the type of the function:
>>
>> graphicsContextCreate :: WindowDC a -> IO (GraphicsContext ())
>>
>> while the paint event callback takes a DC () as argument, which is more
>> general.  It seem wxwidgets needs to know the type of the DC to create
>> a graphicscontext.  Also wxwidgets 2.8 doesn't have a function to create
>> one from a  memoryDC, but 3.0 has.
>>
>> One solution I came up with would be to replace DC () in the paint-event
>> to  MemoryDC (), since it's double buffered, and to PaintDC in a paint-raw
>> event.  This callback would also work with a more general function.
>> Unfortunately it fails on Mac-OS since no memoryDc is used in the paint
>> callback.
>>
>> And it still feels like a low level solution, it would be nicer to have
>> a higher level
>> API that can abstract away these problems.  Maybe making a new paint
>> callback that already includes the graphiccontext?  Also creating a
>> graphicspath from a haskell datatype would be nice.
>>
>> I am willing to help coding this functionality.
>>
>> Regards,
>> Kristof Bastiaensen
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries.  Built-in WAN optimization and the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> wxhaskell-devel mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel