Update image urls to non-transparent version. (#6944)

Author: tomislavhofman

Diff for: docs/Backpressure.md

@@ -20,7 +20,7 @@ Cold Observables are ideal for the reactive pull model of backpressure described
 
 Your first line of defense against the problems of over-producing Observables is to use some of the ordinary set of Observable operators to reduce the number of emitted items to a more manageable number. The examples in this section will show how you might use such operators to handle a bursty Observable like the one illustrated in the following marble diagram:
 
-<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.bursty.png" width="640" height="35" />​
+<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.bursty.v3.png" width="640" height="35" />​
 
 By fine-tuning the parameters to these operators you can ensure that a slow-consuming observer is not overwhelmed by a fast-producing Observable.
 
@@ -33,23 +33,23 @@ The following diagrams show how you could use each of these operators on the bur
 ### sample (or throttleLast)
 The `sample` operator periodically "dips" into the sequence and emits only the most recently emitted item during each dip:
 
-<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.sample.png" width="640" height="260" />​
+<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.sample.v3.png" width="640" height="260" />​
 ```java
 Observable<Integer> burstySampled = bursty.sample(500, TimeUnit.MILLISECONDS);
 ```
 
 ### throttleFirst
 The `throttleFirst` operator is similar, but emits not the most recently emitted item, but the first item that was emitted after the previous "dip":
 
-<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.throttleFirst.png" width="640" height="260" />​
+<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.throttleFirst.v3.png" width="640" height="260" />​
 ```java
 Observable<Integer> burstyThrottled = bursty.throttleFirst(500, TimeUnit.MILLISECONDS);
 ```
 
 ### debounce (or throttleWithTimeout)
 The `debounce` operator emits only those items from the source Observable that are not followed by another item within a specified duration:
 
-<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.debounce.png" width="640" height="240" />​
+<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.debounce.v3.png" width="640" height="240" />​
 ```java
 Observable<Integer> burstyDebounced = bursty.debounce(10, TimeUnit.MILLISECONDS);
 ```
@@ -64,14 +64,14 @@ The following diagrams show how you could use each of these operators on the bur
 
 You could, for example, close and emit a buffer of items from the bursty Observable periodically, at a regular interval of time:
 
-<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.buffer2.png" width="640" height="270" />​
+<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.buffer2.v3.png" width="640" height="270" />​
 ```java
 Observable<List<Integer>> burstyBuffered = bursty.buffer(500, TimeUnit.MILLISECONDS);
 ```
 
 Or you could get fancy, and collect items in buffers during the bursty periods and emit them at the end of each burst, by using the `debounce` operator to emit a buffer closing indicator to the `buffer` operator:
 
-<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.buffer1.png" width="640" height="500" />​
+<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.buffer1.v3.png" width="640" height="500" />​
 ```java
 // we have to multicast the original bursty Observable so we can use it
 // both as our source and as the source for our buffer closing selector:
@@ -86,14 +86,14 @@ Observable<List<Integer>> burstyBuffered = burstyMulticast.buffer(burstyDebounce
 
 `window` is similar to `buffer`. One variant of `window` allows you to periodically emit Observable windows of items at a regular interval of time:
 
-<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.window1.png" width="640" height="325" />​
+<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.window1.v3.png" width="640" height="325" />​
 ```java
 Observable<Observable<Integer>> burstyWindowed = bursty.window(500, TimeUnit.MILLISECONDS);
 ````
 
 You could also choose to emit a new window each time you have collected a particular number of items from the source Observable:
 
-<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.window2.png" width="640" height="325" />​
+<img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.window2.v3.png" width="640" height="325" />​
 ```java
 Observable<Observable<Integer>> burstyWindowed = bursty.window(5);
 ```
@@ -158,11 +158,11 @@ For this to work, though, Observables _A_ and _B_ must respond correctly to the
 
 <dl>
  <dt><tt>onBackpressureBuffer</tt></dt>
-  <dd>maintains a buffer of all emissions from the source Observable and emits them to downstream Subscribers according to the <tt>request</tt>s they generate<br /><img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.obp.buffer.png" width="640" height="300" /><br />an experimental version of this operator (not available in RxJava 1.0) allows you to set the capacity of the buffer; applying this operator will cause the resulting Observable to terminate with an error if this buffer is overrun​</dd>
+  <dd>maintains a buffer of all emissions from the source Observable and emits them to downstream Subscribers according to the <tt>request</tt>s they generate<br /><img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.obp.buffer.v3.png" width="640" height="300" /><br />an experimental version of this operator (not available in RxJava 1.0) allows you to set the capacity of the buffer; applying this operator will cause the resulting Observable to terminate with an error if this buffer is overrun​</dd>
  <dt><tt>onBackpressureDrop</tt></dt>
-  <dd>drops emissions from the source Observable unless there is a pending <tt>request</tt> from a downstream Subscriber, in which case it will emit enough items to fulfill the request<br /><img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.obp.drop.png" width="640" height="245" />​</dd>
+  <dd>drops emissions from the source Observable unless there is a pending <tt>request</tt> from a downstream Subscriber, in which case it will emit enough items to fulfill the request<br /><img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.obp.drop.v3.png" width="640" height="245" />​</dd>
  <dt><tt>onBackpressureBlock</tt> <em style="color: #f00;">(experimental, not in RxJava 1.0)</em></dt>
-  <dd>blocks the thread on which the source Observable is operating until such time as a Subscriber issues a <tt>request</tt> for items, and then unblocks the thread only so long as there are pending requests<br /><img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.obp.block.png" width="640" height="245" /></dd>
+  <dd>blocks the thread on which the source Observable is operating until such time as a Subscriber issues a <tt>request</tt> for items, and then unblocks the thread only so long as there are pending requests<br /><img src="https://github.com/ReactiveX/RxJava/wiki/images/rx-operators/bp.obp.block.v3.png" width="640" height="245" /></dd>
 </dl>
 
 If you do not apply any of these operators to an Observable that does not support backpressure, _and_ if either you as the Subscriber or some operator between you and the Observable attempts to apply reactive pull backpressure, you will encounter a `MissingBackpressureException` which you will be notified of via your `onError()` callback.

Diff for: docs/Blocking-Observable-Operators.md

@@ -18,7 +18,7 @@ To transform an `Observable` into a `BlockingObservable`, use the [`Observable.t
 
 > This documentation accompanies its explanations with a modified form of "marble diagrams." Here is how these marble diagrams represent Blocking Observables:
 
-<img src="/ReactiveX/RxJava/wiki/images/rx-operators/B.legend.png" width="640" height="301" />
+<img src="/ReactiveX/RxJava/wiki/images/rx-operators/B.legend.v3.png" width="640" height="301" />
 
 #### see also:
 * javadoc: <a href="http://reactivex.io/RxJava/javadoc/rx/observables/BlockingObservable.html">`BlockingObservable`</a>

Diff for: docs/Connectable-Observable-Operators.md

@@ -7,7 +7,7 @@ This section explains the [`ConnectableObservable`](http://reactivex.io/RxJava/j
 
 A Connectable Observable resembles an ordinary Observable, except that it does not begin emitting items when it is subscribed to, but only when its `connect()` method is called. In this way you can wait for all intended Subscribers to subscribe to the Observable before the Observable begins emitting items.
 
-<img src="/ReactiveX/RxJava/wiki/images/rx-operators/publishConnect.png" width="640" height="510" />
+<img src="/ReactiveX/RxJava/wiki/images/rx-operators/publishConnect.v3.png" width="640" height="510" />
 
 The following example code shows two Subscribers subscribing to the same Observable. In the first case, they subscribe to an ordinary Observable; in the second case, they subscribe to a Connectable Observable that only connects after both Subscribers subscribe. Note the difference in the output:
 

Diff for: docs/How-To-Use-RxJava.md

@@ -285,7 +285,7 @@ onNext => value_14_xform
 
 Here is a marble diagram that illustrates this transformation:
 
-<img src="/Netflix/RxJava/wiki/images/rx-operators/Composition.1.png" width="640" height="536" />
+<img src="/Netflix/RxJava/wiki/images/rx-operators/Composition.1.v3.png" width="640" height="536" />
 
 This next example, in Clojure, consumes three asynchronous Observables, including a dependency from one to another, and emits a single response item by combining the items emitted by each of the three Observables with the [`zip`](http://reactivex.io/documentation/operators/zip.html) operator and then transforming the result with [`map`](http://reactivex.io/documentation/operators/map.html):
 
@@ -333,7 +333,7 @@ The response looks like this:
 
 And here is a marble diagram that illustrates how that code produces that response:
 
-<img src="/Netflix/RxJava/wiki/images/rx-operators/Composition.2.png" width="640" height="742" />
+<img src="/Netflix/RxJava/wiki/images/rx-operators/Composition.2.v3.png" width="640" height="742" />
 
 The following example, in Groovy, comes from [Ben Christensen’s QCon presentation on the evolution of the Netflix API](https://speakerdeck.com/benjchristensen/evolution-of-the-netflix-api-qcon-sf-2013). It combines two Observables with the [`merge`](http://reactivex.io/documentation/operators/merge.html) operator, then uses the [`reduce`](http://reactivex.io/documentation/operators/reduce.html) operator to construct a single item out of the resulting sequence, then transforms that item with [`map`](http://reactivex.io/documentation/operators/map.html) before emitting it:
 
@@ -350,7 +350,7 @@ public Observable getVideoSummary(APIVideo video) {
 
 And here is a marble diagram that illustrates how that code uses the [`reduce`](http://reactivex.io/documentation/operators/reduce.html) operator to bring the results from multiple Observables together in one structure:
 
-<img src="/Netflix/RxJava/wiki/images/rx-operators/Composition.3.png" width="640" height="640" />
+<img src="/Netflix/RxJava/wiki/images/rx-operators/Composition.3.v3.png" width="640" height="640" />
 
 ## Error Handling