Let about half the tiles move around in one direction (in front of the
slide plane), and the rest the other direction (behind the slide
plane).
Make sure tiles that rotate into each other's location go the same way
around, so that they don't pass through each others, which looks ugly.
Avoid z-fighting by not letting the tile end up exactly on top of the
one it is replacing, in case that one has not started moving yet.
Change-Id: I232b0f815412d5d575b0dde4df2d337288e645bb
I was suffering from one basic misunderstanding: I did not get it that
samplers are indexed with normalized texture coordinates, i.e. 0..1.
(Note that multiplying a coordinate by any number does not break
anything horribly for this use case, looking up a pseudo-random
number, because textures by default repeat as a coordinate wraps.)
We multiply by 10 so that neighbouring pixels that map to close index
into the permTexture don't get clumped together with close sn values,
and thus same behaviour.
(Sure, the multiplication by 256 that I had changed it to worked, too,
but not the way my initial reasoning went... So let's use the original
10 to avoid somebody else thinking that we need to multiply by 256
because permTexture is built from a 256x256 array.)
(See 1877228ae8)
Change-Id: I1d350446460fe2fdd3e55f00053a5ce01d2d117c
Use #version 120 explicitly, and adapt the shader shader code
accordingly, to use strictly only GLSL 1.20 constructs. Also, use less
vertex attribute data in the Vortex vertex shader: We can pack the
per-vertex tile x and y index and in-tile vertex index information
into one float. Also, the shader can calculate the center of the tile
a vertex belongs to based on the knowledge of which tile it is.
Now the shader transitions work on OS X, too.
Change-Id: I93e8b5069a6d06d2e412ffee322b1eb32805e606
The actual transition is not yet at all like the one in the competing
product. But some basic ideas are in place.
Change-Id: Ie17a4fe03ae93abe51a2f1f760f417ee4b193e2c
All of the remaining includes of boost/bind.hpp may be removed from
slideshow, as last remaining uses of boost::bind have been removed from
the module. There should be no side effects due to this change.
Change-Id: I4e1855545fad69d09e594d0be139c09aad561b2d
Reviewed-on: https://gerrit.libreoffice.org/19395
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Replace boost::bind with C++11 lambdas. In addition, replace the use of
FuncT::result_type in ListenerOperations::notifyAllListeners with a less
type specific means of determining the return type of the function to be
applied in order to allow for the use of C++11 lambdas.
Change-Id: I1035be976e542d8b5bbd451c473a896d91ed66ca
Reviewed-on: https://gerrit.libreoffice.org/19314
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
Replace simple while loops with range-based for-loops when apropriate.
There should be no side effects due to this change.
Change-Id: I0c39d4c10c991354248e864a09333144974c953c
Reviewed-on: https://gerrit.libreoffice.org/19281
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
Replace ::std::for_each for a more readable range-based for loop in
cases in which the function object to be applied by for_each is more
readable as the body of a for loop.
Change-Id: I5798293cdd0d784cc4c95c67e3fc6a0b930db8bb
Reviewed-on: https://gerrit.libreoffice.org/19261
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
...moved here with 6fbab2ce87 "loplugin:unreffun";
this file still indirectly includes boost/scoped_ptr.hpp via. boost/spirit
Change-Id: Ib2f251420950395f58415c1f7c944b7e8fd61476
For some reason with gtk3 events are handled a bit differently, and in
particular after the PresenterSlideShowView::Resize() sets the
mbIsForcedPaintPending = true, with gtk2 we get a
notifySlideAnimationsEnded event and then a notifyViewChanged event that
calls PresenterSlideShowView::clear() to reset the flag,
but with gtk3 the flag isn't reset and then
PresenterSlideShowView::ForceRepaint() destroys the SlideView,
while there are still events in the EventQueue with pointers to it.
Since i'm evidently too dumb to tell what of this event handling is
working correctly and what is buggy, avoid the crash by checking
that the SlideView is still alive in the event handlers.
Change-Id: Ib88e61536c21e9787cef8a436341bfbd89914f4b
