Zoom about fdwaveformview HOT 12 CLOSED

Please help test this branch.

With each frame of dragging, the entire waveform is being redrawn. The way to fix that is to use caching. Any helpers with this?

• Make a larger PNG than we need using bleedMargin (similar to using targetOverDraw and minimumOverDraw)
• When rendering image and highlightedImage use the bleed and set cachedStartSamples and cachedEndSamples appropriately
• When rendering, if the cached image (image, highlightedImage) are usable and respect the minimumOverDraw then stretch it, otherwise replot

from fdwaveformview.

Please help review the code at 22ec8e6

The code implements the proposal in the previous comment but is not working quite right. Caching is the ticket to buttery smooth scrolling and stretching.

from fdwaveformview.

Unfortunately being that I'm using FDWaveformView from RubyMotion, I'm not going to be much help in code review as Obj-C with all it's Header files and Pointers is a bit above my head! However, I have just downloaded the latest FDWV and I do have a few thoughts.

First, it would make sense to me to zoom the waveform image currently rendered and only then swap that out once an updated one has been rendered. From a user perspective this would provide much more feedback as to what they are doing. This way, you wouldn't need to actually call a render function until the user has finished performing the gesture. I may be wrong, but I think your overdraw renders are occurring with each call of render on zooming (which wouldn't make sense if the user hasn't finished zooming in/out)?

I'm not sure if this would severely hinder performance and/or image quality, but it would also seem to me to make sense to make the first render at a higher x-resolution if doesAllowStretchAndScroll is set to true, so that a small amount of zooming doesn't require re-rendering (and this would presumably work hand in hand with the suggestion above of just zooming the image before re-rendering).

from fdwaveformview.

What you have described is exactly how it is supposed to be implemented. Whether it works or not has yet to be tested!

from fdwaveformview.

Ok in which case, putting an NSLog at the start of renderPNGAudioPictogramLogForAsset: shows that the rendering is being called as soon as you start to pinch. I may be wrong, but would it be correct to do the following with the last part of the Pinch recogniser?

if ([recognizer state] == UIGestureRecognizerStateEnded) {
    self.image.image = nil;
    self.highlightedImage.image = nil;
    [self setNeedsDisplay];
    [self setNeedsLayout];
    recognizer.scale = 1;
}

And Then before that place some code that just handles image zooming with the image currently in memory?

from fdwaveformview.

Better conditionals minimize drawing to when actually needed. WAY smoother now

from fdwaveformview.

This is fantastic! Well done on getting it working. A couple of little quirks I’ve noticed:
If the waveformview isn’t the full width of the window, zooming results in the waveform escaping outside it’s frame.
There becomes a zoom level whereby the rendering seems to break down and the result is just part of the waveform followed by white.

Otherwise this really is superb :)

from fdwaveformview.

I have not been able to reproduce this issue. It is still an issue with the latest version? (master)

Thank you!

from fdwaveformview.

Hi. Yes it is. Not sure which of the two issues you mean:

If it's the first, then it really is as simple as initWithFrame to a width less than the window width, enable stretchandscroll and then watch as you zoom in, the image escapes outside the edges of the frame you've initialised the waveform in.
If it's the second, then the key may actually be to do with the length of the audio file. I just tried with the test file in the project and didn't seem to get it. However using a track ~5 minutes long, you can zoom in to a level that seems as thought it should be able to go further, and then you lose most of the image.

Hope this helps!

from fdwaveformview.

Hi @pixlwave Just wanted to follow up, does this project still wore with RubyMotion? And is there anything we should add to our test suite to support this target?

from fdwaveformview.

So I no longer use RubyMotion, but I believe that since the move to Swift this project no longer works with it for 2 reasons:

• RubyMotion needs Objective-C headers in order to generate the bridge to the Objective-C runtime. This one would be fixable by enabling Xcode to auto-generate the headers, however;
• I don't believe that RubyMotion is aware to copy in the necessary swift runtime libraries in this situation so the user needs to do so manually (I was experimenting with this around the time I decided to learn Swift and can't remember the specifics of how well it worked).

All this said, I believe that Swift compatibility is one of the aims of RubyMotion to move forwards, and to answer your second question, if they implement this in the same way as their Objective-C bridge, it would be very unlikely that any additional tests would be required as it's a pretty much transparent process.

from fdwaveformview.

Thank you for explaining. Excellent. So it appears that we do not need to worry about them being downstream.

from fdwaveformview.