Yeah application surface matters. For the various sizes, starting from the beginning of the pipe... Room size does not matter at all. View size (and position) matters in grabbing part of the room to be displayed, so can scale stuff by deciding how much is visible. Application surface size is the base approximation scale of room content. If your view versus app surface size is not identical, the positions and scales of sprites get multiplied by the difference before drawn to app surface. Meaning, if view and app surface are 1:1 then no scaling whatsoever happens. (Room coordinate positions will be rounded to app surface pixel positions; this doesn't matter if view is 1:1 but will matter if you're upscaling fractional positions.) Setting a small view and large app surface is how pixel art is typically upscaled with GMS2. The fullscreen display or window then receives the app surface. I don't know if the automated draw process will stretch to fit as I've been running my display system with application_surface_draw_enable
turned off and draw it myself, which will not stretch unless I tell it to. Then there's also the view port stuff, which I've never used but can be used to assign only a portion of the fullscreen or window to receive the app surface content.
(Aside: those using view to app surface upscaling technique should take note of the above. If your coordinates are not integers all the time, it can create partial sprite overlap that collision functions will not detect. This is because collisions happen in room space and get rounded before collisions are checked. But drawing will happen in app surface space using multiplied coordinates rounded after multiplication. So if your coordinate value is 3.4 collisions for that instance are checked at 3.0. And if your upscale is 5 it gets drawn to coordinate value 3.4 * 5 = 17, not 15 where the collision was checked. This would be avoided if collision commands worked with fractions, but they don't.)