According to the documentation `read` isn't required to read all the
data requested. Although until recently I'd never encountered this and
none of Blender's code checks for read succeeding but not reading the
requested size.
Resolves#113473 where images over 2gb fail to load.
Ref !113474.
The image size was used to set the window size, large values could
make the window fail to create it's GPU context.
Resolve by constraining window size by the main display dimensions.
Even in cases where the window would succeed to create its generally
not useful to have a window larger than the screen size.
While passing in multiple files is supported, scrubbing both images
an movies wasn't working properly when multiple files were passed in.
For images, arguments such as "*.png" expand to multiple image files
which were each assigned a frame index of 0, this would play but stopped
scrubbing from working completely.
For movies, passing in multiple files would play back all files but
only properly scrub the first file, if other videos were longer than
the first scrubbing would jump to those.
Resolve by starting the frame index where the previous files left off.
Also resolve divide by zero when showing the indiciator for a single
frame.
Removing one unnecessary check in wm_link_append_exec that caused us to
error out even though multiple files are selected. This removed check
is also done later on in the function so safety is still ensured.
Pull Request: https://projects.blender.org/blender/blender/pulls/113350
Move the three current 'status variables' (stop, update and progress)
into a single 'WorkerStatus' struct. This is cleaner and will allow for
future workin this area without having to edit tens of 'startjob'
callbacks signatures all the time.
No functional change expected here.
Note: jobs' specific internal code has been modified as little as
possible, in many cases the job's own data still just store pointers to
these three values. Ideally in the future more refactor will be using a
single pointer to the shared `wmJobWorkerStatus` data instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/113343
In some cases processing events was modifying them, as there can be
multiple event consumers, manipulating events isn't correct.
Even though in practice it didn't cause issues, it's straightforward
not to do this and makes logic easier to reason about.
IME editing would cast GHOST_TEventImeData to wmIMEData then read/write
an additional member that doesn't exist in GHOST_TEventImeData.
In practice it's likely struct padding prevented this from showing up
as a bug. Nevertheless it's bad practice to rely on this.
- Make GHOST_TEventImeData read-only, move the is_ime_composing boolean
into the window.
- Add static assert to ensure both structs are the same size.
- Correct code comments.
This PR implements an initial drawing tool that can already be used for testing.
While this is not fully feature complete (compared to the current grease pencil draw tool) the following is already implemented:
* Pressure support for radius and opacity.
* Material color and vertex color support.
* New active smoothing algorithm based on curve fitting.
* Simplify algorithm as a post-process step.
Some deliberate limitations include:
* The drawing plane is always the front plane. Drawing on surfaces is also not supported.
*
The current approach has not been optimized for performance yet. The goal was to have a straightforward implementation
first and then focus on performance later.
There are numerous parameters in the code that are hard-coded for now. These should be exposed at some point, potentially as user settings.
Pull Request: https://projects.blender.org/blender/blender/pulls/110093
Resizing a window in Wayland caused cursor motion events in the window
which could be seen as buttons flashing when the cursor was detected
as hovering over buttons.
This was caused by two bugs:
- Missing checks for failure to access the cursor location before
converting the coordinates from GHOST to screen-space meant the
wmWindow::eventstate location would move each time the location
was updated.
- Resizing the window wasn't detecting state changes and would
continuously send window activation events. Window activation set
wmWindpw::addmousemove which triggered the previous bug, making the
cursor flicker during resize.
This commit only addresses the first issue, where failure to access
the cursor location wasn't accounted for
(window activation will be fixed separately).
All GHOST_GetCursorPosition & wm_cursor_position_get calls now account
for failure, resolving uninitialized stack memory use in some cases.
This resolves similar issues for macOS, WIN32 & X11 although it seems
likely these platforms rarely fail to access the cursor location.
For some reasons, `WM_jobs_stop` and `WM_jobs_kill` would use their own
'type' of function pointer - and not even a matching one!
Among (many) other reasons why this was bad, it required very stupid
casting from code using these functions - and made editing wmJob `startjob`
signature needlessly complicated.
