Why BendiStudio RIPs Faster: Concurrent GPU Rasterization and Full Thread Utilization

Every RIP on the market will tell you it is fast. Very few will let you tick five jobs in a queue, press one button, and watch all five rasterize at the same moment. That is what the clip below shows, recorded on a BendiStudio workstation: several jobs selected in Hold, one click on RIP, and every card lands in the Output Queue and starts assembling its own image while its data is being built on the graphics card.

Batch RIP in BendiStudio 1.7.9x: multiple jobs ticked in Hold, one click, all of them ripping concurrently on the GPU. No cuts, no speed-up.

1. What a RIP actually has to do

Rasterizing a wide-format job is three separate kinds of work, and the reason most RIP engines feel slow is that they run all three on the same handful of CPU threads, one job at a time. First, the artwork has to be rendered: every placed image is sampled through its rotation, crop and scale into a 600-dpi frame, which for a 48-by-62-inch vehicle panel means more than a billion pixels. Second, every one of those pixels has to be color-managed: converted from the artwork's RGB through the media's ICC profile into the printer's ink channels. Third, the result has to be encoded into the printer's own raster language and written to disk so it can stream to the machine.

Rendering and color are what engineers call embarrassingly parallel: each pixel is independent of its neighbors. Encoding is different: it runs row by row, and each row is expressed as a difference from the row above it. A conventional RIP treats the whole thing as one sequential pipeline. The CPU renders a band, then colors it, then encodes it, then moves to the next band, then, when the job is done, starts the next job. Twenty-four cores sit mostly idle while one or two do all the work.

2. How BendiStudio splits the work

BendiStudio's engine takes the two parallel stages off the CPU entirely and hands them to the graphics card, then gives every CPU core to the one stage that needs it. The pipeline looks like this:

The three stages are connected by bounded queues and run on their own threads, so the GPU is rendering band n+1 while the CPU encodes band n and the network sends band n-3. Nothing holds the whole frame in memory, which is why print length is effectively unlimited and a 50-foot banner does not need 50 feet of RAM.

The same job on a conventional RIP

For context, here is what that panel looks like on the engines most shops run today. A conventional wide-format RIP such as SAi Flexi / Production Manager or Onyx rasterizes on a single thread, one pixel after another, typically in 8 bits per channel, and only starts the next stage when the previous one has finished. On a billion-pixel panel that is a two-to-five-minute wait, not a two-to-four-second one. In our earlier HP Latex 570 benchmark, a comparable fleet-wrap panel took SAi Production Manager 4 minutes 42 seconds to rasterize before the printer saw any data. The chart below uses a conservative 3 minutes for the conventional engine.

3. Concurrency: many jobs, not just many cores

Making one job faster is only half the story. The bigger win in a real shop is that BendiStudio runs several jobs at once. Tick any number of cards in Hold, click RIP, and each job gets its own pipeline: its own GPU scene, its own encode queue, its own file. Up to four heavy pipelines run concurrently by default (a setting you can raise), the rest wait their turn and start the instant a slot frees up. Because the GPU finishes each band in milliseconds and the encoder is the long pole, four jobs sharing 24 cores finish in roughly the time a conventional RIP takes for one and a half.

In the clip above, several jobs go from Hold to the Output Queue and back to "Queued" in a few seconds of wall time, including opening each draft. The cards move immediately, the ink-particle animation on each card is driven by that job's own progress, and the canvas is handed back to you blank so you can keep laying out the next job while the rest are still building. That last part matters more than it sounds: the operator is never waiting on a progress bar.

4. Why other RIP engines don't work this way

The wide-format RIP business is built on engines that were designed when a fast workstation had two cores and no programmable graphics card. Their rasterizers were written for that world and have been carried forward, feature by feature, for twenty years. Adding GPU rendering to a codebase like that is not a feature; it is a rewrite, and a rewrite of the one component every color profile, every driver and every customer's workflow depends on. So the industry has mostly added threads around the edges: a preview here, a spool there, while the core still processes one job through one pipeline.

We are not aware of any other wide-format RIP that rasterizes and color-manages on the GPU in a single pass and runs multiple independent jobs concurrently on top of that. Some engines will queue jobs and start the next as the previous finishes. Some will use a few threads inside one job. None of them, in our testing, will take five jobs from a queue and have all five building at the same instant with the operator free to keep working. BendiStudio can do it because its engine was written in 2026 for 2026 hardware: a compute shader for the pixels, every core for the encoder, and a queue that treats the printer, not the RIP, as the bottleneck it should be.

"Conventional RIP engine" describes the sequential CPU architecture common to legacy wide-format RIPs; individual products vary, and vendors do not publish their internal pipelines. BendiStudio's figures are our own measurements, reproducible in the app's RIP timeline.

5. What the minutes are worth

RIP time is the least visible cost in a print shop because nobody invoices for it. But it sits in front of every job, and the printer cannot run until it is done. Take a modest shop that RIPs twenty jobs a day, with an average of four minutes of RIP and waiting per job on a conventional engine. That is eighty minutes a day in which either the operator or the printer, and usually both, is idle. Cut that to a quarter, which is what concurrent GPU rasterization does on a multi-job batch, and you have recovered an hour every working day.

An hour a day is 250 hours a year. At a fully loaded operator cost of $35 an hour that is $8,750, before counting the printer. An HP Latex running at 200 square feet an hour on a wrap profile produces material a shop sells at $6 to $10 a square foot; an idle hour of printer time is $1,200 to $2,000 of capacity that did not get sold. Even if you only convert a fraction of the recovered hour into printed work, the RIP pays for itself many times over inside the first quarter. The numbers scale with the shop: a busy fleet-graphics operation ripping sixty panels a day is looking at three recovered hours daily.

6. How to use it

1. Lay out each job as usual. Every job you save appears as a card in Hold.
2. Tick the cards you want to build, or leave them unticked and use the ⚡ RIP button on a single card.
3. Click RIP (n) in the queue toolbar. Every card flies to the Output Queue and starts building; the canvas resets to a blank job.
4. Keep working. When each job finishes, its card shows the real thumbnail and the status changes to Queued. Click Send to print them in order, streaming while the printer runs.

On Windows, the GPU path is used automatically on any workstation with a DirectX 12 graphics card, including the integrated graphics in most current desktop processors. On a machine without one, BendiStudio falls back to the multi-core CPU pipeline and the same concurrent queue, so the workflow is identical; only the per-job time changes.

On the Mac: Apple silicon, unified memory and the built-in GPU cores

BendiStudio for Mac is a native Apple silicon build, and the same three-stage pipeline maps onto an M-series chip particularly well. On an Intel or AMD workstation the artwork has to be copied across the PCIe bus into the graphics card's own memory before a single pixel can be rendered, and the finished bands copied back again for encoding. Apple silicon has no such bus to cross: the CPU cores and the GPU cores share one pool of unified memory, so the uploaded artwork, the 65³ colour lookup and every rendered band live in one place and are simply handed from one stage to the next with no copy at all. The GPU cores render and colour-manage a band, the performance cores pick it up in place and encode it, and the efficiency cores keep the queue, the preview and the network stream moving without stealing time from either.

On the latest M-series chips, including the M6 generation with its larger GPU core counts and higher memory bandwidth, that means a MacBook Pro or Mac Studio on the front counter rasterizes a billion-pixel panel in the same handful of seconds as the Windows workstation in the back room, and runs the same four concurrent pipelines while you keep laying out the next job. No external graphics card, no driver installs and no fan noise to speak of: tick the cards, click RIP, and every job builds at once.

Frequently asked questions