search

cathoderaydude / Babel

A simple translation tool for on-screen text using Google Cloud Vision and Translate. Intended for translating emulated videogames and similar things.
MIT License
2 stars 0 forks source link

Fullscreen mode #18

Open cathoderaydude opened 4 years ago

cathoderaydude commented 4 years ago

F11 > Fullscreen would be nice, because if anyone wants to translate a fullscreen app, it would be convenient for them not to have to scroll - so, one monitor taken up by the program, the other taken up by Babel. They would want to be able to access the toolbar either floating, or auto-popup when they mouse to the top.

My first thought would be to use a second form which can appear fullscreen, and generalize much of the code - so that instead of referencing e.g. the picturebox directly, we reference a pointer to same, and then that pointer can either indicate the box on the main form or the one on the fullscreen form.

However, I wonder if this couldn't be accomplished by careful dynamic rearrangement of controls on the main form, e.g., we hide the main layout panel, reattach picturebox to the main window docked, reattach toolstrip to the main window set always on top, and so on.

hbloom1783 commented 4 years ago

can toolstrips autohide? would be nice to keep access to the controls.

have also wondered about scaling the pbx: can we do that in a way that still lets us place phraserects?

cathoderaydude commented 4 years ago

I don't see a way to autohide them, I suspect we'd have to implement that, and its impact on form layout will be complicated

I tested scaling the pbx and yeah, unsurprisingly onpaint does not know the scaling occurred. Thinking about it however, I think we could implement this in a fairly clever way.

PictureBox has a StretchImage mode which will automatically scale the image buffer to fit the control. However, since all our graphics code is in OnPaint, and it refers to the underlying image (via coordinates from the AsyncOCR object), it draws unscaled, because OnPaint occurs after the control has drawn the image scaled.

If, instead, we point the pbx to the 'edit' image buffer, and tell our paint routine to draw directly into that image, when the pbx renders it, all our drawn boxes and text will be scaled along with it. There are two issues:

1) Editing an image is slower than OnPaint, as we discovered - but unless/until we figure this out, we could simply allow scaled mode as a slow-path option and 1:1 mode as fast-path.

2) We need to adapt all mouse input to the scale factor, which shouldn't be that hard - if the scale factor is 50%, we literally divide the mouse position by 2 and we should be golden.

hbloom1783 commented 4 years ago

definitely don't wanna lose any performance. if we can reduce the frequency of invalidates, that might help. it's fine without scaling, though.