Re: resizable ft2demos
> Ok. They also say that PostQuitMessage should get me out of any modal loop. That doesn't seem to be stopping the modal loop when I tested it. And even if you break out of the modal loop the window won't resize properly. Also, the application crashes when the width/height becomes zero. So it should check the values of width/height before `gr_win32_surface_resize' in the `WM_SIZE' message. Anuj
Re: resizable ft2demos
> > > > Indeed we need a callback or... Would a longjmp to break the loop work? > > That would leave user32 in broken internal state. Ok. They also say that PostQuitMessage should get me out of any modal loop. Can I use that mechanism to stop the resizing loop? What If I quit on any message? I should be able to come back because of the main() loop.
Re: resizable ft2demos
Alexei Podtelezhnikov wrote: > On Sat, May 23, 2020 at 6:01 AM Dmitry Timoshkov wrote: > > In addition to CS_HREDRAW | CS_VREDRAW the WM_SIZE handler should call > > DefWindowProc() so that default message processing forces a window update. > > After that the window gets repainted while being resized. > > I've achieved the same effect with CS_HREDRAW | CS_VREDRAW | CS_OWNDC. > It looks funky as if everything is working without the bitmap data > being updated. > Check it out if you have time. I'd suggest to avoid using CS_OWNDC. > > I'd suggest to change the demo design, so that it provides a callback > > to the graphics subsystem for a forced bitmap resize. > > Indeed we need a callback or... Would a longjmp to break the loop work? That would leave user32 in broken internal state. -- Dmitry.
Re: resizable ft2demos
On Sat, May 23, 2020 at 6:01 AM Dmitry Timoshkov wrote: > In addition to CS_HREDRAW | CS_VREDRAW the WM_SIZE handler should call > DefWindowProc() so that default message processing forces a window update. > After that the window gets repainted while being resized. I've achieved the same effect with CS_HREDRAW | CS_VREDRAW | CS_OWNDC. It looks funky as if everything is working without the bitmap data being updated. Check it out if you have time. > I'd suggest to change the demo design, so that it provides a callback > to the graphics subsystem for a forced bitmap resize. Indeed we need a callback or... Would a longjmp to break the loop work? Alexei
Re: resizable ft2demos
A callback function would be definitely much better and simpler than my solution. Anuj
Re: resizable ft2demos
Alexei Podtelezhnikov wrote: > Dmitry, > > It probably needs adding CS_HREDRAW | CS_VREDRAW to ourClass.style. > > That was not enough. Alexei, In addition to CS_HREDRAW | CS_VREDRAW the WM_SIZE handler should call DefWindowProc() so that default message processing forces a window update. After that the window gets repainted while being resized. However that leads to the limitation of the demo that can't update its bitmap contents until the mouse button is released and modal message loop passes control back to the application code. As the result WM_SIZE calls gr_win32_surface_resize() however the source bitmap the demo paints to still has old size and contents, and WM_PAINT gets broken. While Anuj's approach works I'd personally refrain from using it since it basically replaces low level user32 code with custom window resizer. I'd suggest to change the demo design, so that it provides a callback to the graphics subsystem for a forced bitmap resize. -- Dmitry.
Re: Logging Library-GSOC
Hello Priyesh, > Clearly there is some problem with the current logger, but I think > the requirements which are mentioned on the FreeType's GSoC page and > the requirements which are discussed being here are different... I don't think so. It's only that David T. is back, and he wasn't part of the earlier discussions that we had some time ago :-) > Please could you guys guide me with the actual requirements as there > is very little time left for coding to begin... Don't worry about the timing; investigating what to use and how is *part* of GSoC. Irrespective of that, Armin has added some quite useful things that I haven't thought before, and which are definitely worth to be considered and implemented. To summarize: I want an improved logging facility that ideally doesn't change how errors are marked within the FreeType source code (i.e., continued use of `FT_TRACEx`). However, it should provide possibilities to adapt the debugging output data to various needs. 1. Flexible formatting of the messages, for example a. Displaying the tracing component (i.e., the value of the `FT_COMPONENT` macro), and b. Showing a time stamp. 2. Modifying the output stream at runtime. a. Dynamic change of desired output log levels. b. Dynamic log redirection. 3. Hide platform-specific logging details from FreeType. All of this should be configurable either with a config file or with environment variables. I'm not sure how item 2 can be handled best; if this feature is active it maybe makes sense to force re-reading of environment variables and config files as sonn as a FreeType API function is called. To avoid library dependencies, the following seems appropriate. 1. The logging library should be statically linked with FreeType. 2. Its source should be distributed with the FreeType source code bundle: It gets imported into the FreeType git repository as a git submodule, and `make dist` should add it to the distribution tarball. In case there isn't a library that fits our needs, or that cannot be easily adapted to the desired purposes, it's necessary to investigate how to implement at least a part of the above ideas directly in FreeType. Werner
