GPU + CPU are 99.9% going to be faster than any classic CPU-only program. So I wouldn't worry about speed until it's actually a problem. GPUs are insanely fast... even when run incorrectly. But I would focus on eliminating as many "incorrect" styles as possible.
- First, I'd simply port it over, line for line as a baseline. No hard fixes. Just one-liner conversions. Leave all the pixel operations.
Then start chopping away at "bad" things like:
- Avoid per-pixel operations. When possible, swap getpixel and putpixel with draw calls like lines, circles, or full bitmaps (draw the whole GUI box once and cache it in a bitmap instead of redrawing it from scratch). But failing that, even al_draw_pixel can be extremely fast. It's a bottleneck, but that neck may be more than big enough to fit all the pixels you want on any GPU made since the year 2000.
- Avoid memory bitmaps. You "can" do per-pixel oldschool operations on bitmaps by storing them in RAM and then when you're "done" you send the whole thing over to VRAM. That's what locking a bitmap does.
GPUs love drawing textures -> textures. (VRAM to VRAM). They can alpha blend for almost free. They can draw lines, circles, and polygons for almost free. You want fewer, larger "macro" operations instead of many tiny pixel operations because every pixel has to go across the bus and the bus is a HUGE bottleneck. Meanwhile, (generalizing) while "I want red pixel at 5,5" is about as complex on the bus as "I want this 4K texture printed, scaled, and blended at 5,5." It's way better for the bus to say "Draw picture #13." than "Draw the following colors 1,12,23,4,25,35, ..., [1 MB later]"
So when possible, it's way better to store every possible variation of a "thing" finished and rendered into many textures (=tons of KB of VRAM) than to "build" that thing every frame by drawing the little pieces pixel-by-pixel.
If you post some example pictures of your program, we can probably give some more specific insight into "this can easily be cached this way" and "this GUI easily be drawn fast this way".
Oh, and if you have many "memory buffers" those can become textures. So you draw onto those textures, and then draw the textures to the screen. Just like before. It'll be slower than ideal, but it's still possible to keep the code as-was-designed that way. Then you can move toward optimizing them.