The version of Texture::setBitmap() that tool an Android bitmap handled
callbacks differently and in certain case caused a "double release" of
the callback object. This didn't actually cause problems though.
We now use the same mechanism used elsewhere (i.e. JniCallback).
- constant bias and normal bias default values in java didn't match
C++ or the documentation
- stable shadows were enabled by default in java
- polygon offset biases were missing from the java API
- document and don't apply polygon offset to VSM
- remove unused code
- move the control code out of FrameInfo and into
View itself. FrameInfo now just gathers information about the
frames instead of also doing part of the control.
- the control code has been refactored into a more formal PIDController.
- a few bugs were fixed in the control loop and default parameters
tuned.
The control loop itself now outputs a relative scale factor instead
of an absolute one. The relative scale factor seems easier to
control and is less jittery, and doesn't have to rely on the "integral"
term of the PID.
It's possible that more tuning is needed, but the scaling is now
more stable.
- defaults to 31 history points instead of 3, this gives a much better
estimate of the frame rate.
- make sure the calculations work for any definition of our internal
duration<> (it's useful to use milliseconds when dealing with
refresh periods).
- don't round to 8 pixels if the scale factor is exactly 1
- fix a few comments and warnings
Java callbacks are now directly dispatched to their handler, instead
of first going through filament's opportunistic dispatch, reducing
callback latency.
A new Engine::pumpMessageQueues() method can be used to trigger all
pending user callbacks right away. This can help reducing latency
of certain callbacks such as picking queries.
This is typically called once before calculating the next frame's
parameters (e.g. object positions or appearance that may depend on a
callback result).
Fix some comments and documentation.
This is a pixel accurate implementation of picking. Picking queries
can be created on view, and upon completion a user provided callback
is called with the Entity of the renderable at the queried coordinates
in the viewport.
Picking queries typically have 1 or 2 frame of latency and may impact
performance on some drivers.
It is mostly intended for use by editors, or when latency is not a major
concern. This api should not be used for dragging/moving objects, it is
intended for initial picking only.
Picking is implemented in the structure pass.
The depth buffer value is retrieved and the fragment coordinate is
reconstructed and passed to PickingQueryResult. This can be used in
turn to calculate the view and/or world space position.
