The problem here is that you are designing code for synthesis without really understanding what that means.
Synthesis generates hardware to implement your design : think about the implications of a loop whose range is not constant : it implies that, as you change the loop limits, hardware magically appears or disappears to implement that change.
Ain't gonna happen; at least not in today's FPGAs.
So, you have to transform your algorithm to one with static loop constraints.
For example, you can transform
for i in cursor_pos_x to cursor_pos_x + length - 1 loop
subtype my_loop_range is natural range min_x to max_x;
for i in my_loop_range loop
if i >= cursor_pos_x and i < cursor_pos_x + length then
Now you always loop over the entire range, but only if two comparators comparing the loop index with your variable (or signal) bounds say "yes", will the
do_something block be enabled.
While loops are worse : there is in general no definite loop limit, so synthesis tools may support them even more poorly.
Incidentally, you do realise that (in a clocked process) your loop will be completely unrolled, generating enough hardware to run the whole loop in a single clock cycle, right? If you have two nested loops with 250 iterations each, that'll be quite a lot of hardware...